29
points
madars
Joined 4,868 karma
- On Reddit, author says "The preview is shown at 20fps for a 3x scale image (90x90 pixels) and 50fps for a 1x scale image. This is due to the time it takes to read the image data from the sensor (~10ms) and the max write speed of the display.", and adds that optical mice motion tracking goes to 6400 fps for this sensor but you can't actually transmit image at that rate.
https://old.reddit.com/r/electronics/comments/1olyu7r/i_made...
- Yes, it works the same way even for content Google indexed at publication time. For example, here are chatgpt.com links that Google displays as being from 2010-2020, a period when Google existed but ChatGPT did not:
https://www.google.com/search?q=site%3Achatgpt.com&tbs=cdr%3...
So it looks like Google uses inferred dates over its own indexing timestamps, even for recently crawled pages from domains that didn't exist during the claimed date range.
- Date displayed in Google Search results is often the self-described date from the document itself. Take a look at this "FOIA + before Jan 1, 1990" search: https://www.google.com/search?q=foia&tbs=cdr:1,cd_max:1/1/19...
None of these documents were actually published on the web by then, incl., a Watergate PDF bearing date of Nov 21, 1974 - almost 20 years before PDF format got released. Of course, WWW itself started in 1991.
Google Search's date filter is useful for finding documents about historical topics, but unreliable for proving when information actually became publicly available online.
- That's a very good question. It all depends on how you pick the witness b: there is a procedure that definitely is not zero-knowledge: say, if prover uses his knowledge of factorization to construct an explicit b that betrays that factorization.
For example, if n = p1*p2*...*pk is square-free and not a Carmichael number, then by Korselt's criterion there exists a pi such that pi-1 does not divide n-1 (this also implies that pi>2). Use the Chinese Remainder Theorem to produce b such that b=1 (mod pj) for all j!=i, and b (mod pi) is a generator of (Z/piZ)^*. Then b is a Fermat witness: gcd(b, n) = 1 (because b is non-zero modulo every prime factor) and b^(n-1) != 1 (mod n) because b^(n-1) != 1 (mod pi) (as pi-1 does not divide n-1).
However, b "betrays" the prime factorization of n, since gcd(b-1, n)>1 (by construction b-1 is divisible by all pj with j!=i, but not divisible by pi>2), and thus gcd(b-1, n) is a non-trivial factor of n. (I assumed square-free above but if pi^ei (ei>=2) divides n, then b=1+pi^(ei-1) (mod pi^ei), b=1 (mod pj^ej) (j!=i) also would have worked.)
On the other hand, it is also known that for non-Carmichael numbers at least half of the bases b with gcd(b, n) = 1 are Fermat witnesses. So if you pick b uniformly at random, the verifier does not gain any new information from seeing b: they could have sampled such a witness themselves by running the same random test. Put another way, the Fermat test itself is an OK ingredient, but a prover who chooses b in a factorization-dependent way can absolutely leak the factors - the final protocol won't be ZK.
- Good background reading/watching - Terence Tao's "The Notorious Collatz conjecture" talk. https://www.youtube.com/watch?v=X2p5eMWyaFs Slides: https://terrytao.wordpress.com/wp-content/uploads/2020/02/co...
I especially like how he highlights that Collatz conjecture shows that a simple dynamical system can have amazingly complex behavior; also 3n-1 variant has two known cycles - so "any proof of the Collatz conjecture must at some point use a property of the 3n+1 map that is not shared by the 3n-1 map." And this property can't be too general either - questions about FRACTRAN programs (of which Collatz conjecture is a special case) can encode the halting problem.
If you haven't seen it, FRACTRAN itself is amazing - https://www.cs.unc.edu/~stotts/COMP210-s23/madMath/Conway87.... and the paper is pure joy to read.
- Project website: https://satcom.sysnet.ucsd.edu/
Paper (CCS '25): https://satcom.sysnet.ucsd.edu/docs/dontlookup_ccs25_fullpap...
- Of course, but the choice is standard and thus the answer is 9. I can define a non-standard sqrt(x) which sometimes gives the positive root and sometimes the negative one, and then sqrt(sqrt(16)) could be -2 or undefined (if I defined sqrt(16)=-4) but that's just silly - the only reasonable interpretation for what the calculator should show for sqrt(sqrt(16)) is simply 2.
- There is no choice here - each inverse is uniquely determined. That's similar to how 3 and -3 are both square roots of 9 (i.e., solutions to x^2=9), but sqrt(9)=3 as it denotes the principal square root, which by convention is always the non-negative value. Of course, in a different context we might design functions to have multi-valued properties, like atan2(x,y) != atan(y/x) in general (atan2 takes quadrant in account and returns full range [-pi, pi], atan only returns principal values in [-pi/2, pi/2]) as practical applications benefit from preserving quadrant beyond just the principal inverse (or not failing when x=0!)
- arcsin(arccos(arctan(tan(cos(sin(9)))))) = 9 (in degrees mode - when regular trig functions output pure numbers, those numbers get interpreted as degrees for the next function and similar for inverses - calculator style), because each intermediate lands in the principal-value domain of the next inverse (e.g., arctan(tan(x)) = x when x \in (-90°, 90°) and the intermediates happen to be in those ranges). Specifically, sin(9°) ≈ 0.156434, cos(0.156434°) ≈ 0.999996, arctan(tan(0.999996°)) = 0.999996°, arccos(0.999996)≈0.156434°, arcsin(0.156434)≈9°.
- 17 points
- 110 points
- 6 points
- Anubis is MIT licensed so you should be able to modify it freely: https://github.com/TecharoHQ/anubis/blob/main/LICENSE It would be very funny if they did that though.
- By the way, you can also construct heap in linear time - instead of doing n consecutive insertions, at least half of which require log n work, you can apply sift-down operations from bottom up, beginning with the last non-leaf node and working backwards to the root.
That way, roughly half the nodes are leaves (requiring no work), a quarter are at the second-to-last level (requiring at most 1 comparison/swap), an eighth at the third-to-last level (requiring at most 2 comparisons/swaps), and so on. Summing up 1 n/4 + 2 n/8 + ... gets you O(n) total complexity.
See https://en.wikipedia.org/wiki/Heapsort?useskin=monobook#Vari...
- 104 points
- Integrated Intel GPU and no graphical system, just KMS VT (text console). That's what made it so frustrating - only displaying a console should not result in kernel panics under CPU load! Admittedly, the experience was anecdotal and years ago and I heard Debian is doing less of a RHEL-style "frankenkernel" now.
- >I've never had a Debian system break without it being my fault in some way.
Debian is great but I can't say this is a shared experience. In particular, I've been bitten by Debian's heavy patching of kernel in Debian stable (specifically, backport regressions in the fast-moving DRM subsystem leading to hard-to-debug crashes), despite Debian releases technically having the "same" kernel for a duration of a release. In contrast, Ubuntu just uses newer kernels and -hwe avoids a lot of patch friction. So I still use Debian VMs but Ubuntu on bare metal. I haven't tried kernel from debian-backports repos though.
- The blog kept redirecting to the home page after a second, so here's an archive: https://archive.is/SE78v
https://archive.is/tKZmn
FWIW, this seems to be a Reuters report reprinted in Japan Times. Previous HN discussions got just a couple comments:
https://www.hackerneue.com/item?id=46301877 https://www.hackerneue.com/item?id=46307819