Show HN: Private real-time dictation app for Mac (github.com)
9 points by aviaryan 9h ago 2 comments
Show HN: QuizKnit, an open source quiz creator (quizknit.com)
3 points by jibolash 6h ago 0 comments
Show HN: My Cross-Platform MySQL Parser (abbychau.github.io)
4 points by abbychau 11h ago 0 comments
Stuffed-Na(a)N: stuff your NaNs
156 dgroshev 58 4/26/2025, 2:04:01 PM github.com ↗
https://piotrduperas.com/posts/nan-boxing
If I encode data into the exponent of these NaN values, propagate them around the internet, and decode them elsewhere.... is that a security risk? Or this just falls into the category of "weird encryption"
The original post seems really weird to me. I would have dismissed it as someone's hobby project, but... that doesn't seem like what it's trying to be.
NaNboxing lets you use less memory on certain use cases. Because memory access is slow and caches are fixed size, this is usually a performance win, even if you have to do a few extra ops on every access.
https://bugzilla.mozilla.org/show_bug.cgi?id=1393085
The API for `getpayload`/`setpayload`/`setpayloadsig` looks a little funny but it's easy enough to wrap (just consider the edge cases; in particular remember that whether 0 is valid for quiet or signaling NaNs is platform-dependent).
Finally we have a reliable `roundeven`, and the convenience of directly calling `nextup`/`nextdown` (but note that you'll still only visit one of the zeros).
The new `fmaximum` family is confusing, but I think I have it clear:
`totalorder` has been often-desired; the other new comparisons not so much.`rootn` and `compoundn` are surprisingly tricky to implement yourself. I still have one testcase I'm not sure why I have to hand-patch, and I'm not sure which implementation choice keeps the best precision (to say nothing of correct rounding mode).
Out of curiosity, isn't this what you'd pretty much universally want? Or maybe I misunderstand the intent here?
That said, quite often you need to handle signed zero specially already, and if you don't the property you're testing might sufficiently differ in the interesting way for the smallest-magnitude subnormals.
In the "before" use-cases, the programmer has accidentally written a bug and gets back a single NaN from a logical operation they performed as a result.
In the "after" cases, the programmer already has some data and explicitly decides to convert it to a NaN encoding. But instead of actually getting back a NaN that is secretly carrying their data, they actually get a whole array of NaN's, which duck type differently, and thus are likely to disappear into another NaN or an undefined if they are propagated through an API.
Like.. I get that the whole thing is supposed to be humorously absurd but... It just doesn't land unless there's something technical I'm missing to connect up the pieces.
Itanium had a bit for "not a thing" for integers (and perhaps some older hardware from around the time floats started being a thing had similar things), so the idea of hardware support for not-a-* isn't exclusive to floats, but evidently this hasn't caught on; generally it's messy because it needs a bit pattern to yoink, but many types already use all possible ones (whereas floats already needed to chop out some for infinities).
Are there any common string operations with similar behavior?
Unicode’s � is basically a symbol for not-a-char.
For example:
In this case it should probably print +inf when i == 0.But:
Now it is not clear, but at least we know it's an infinity so perhaps we need a special value +-inf.And:
In this case, the value for 0/0 can be 1.https://www.gnu.org/software/libc/manual/html_node/Infinity-...
Taking, say, the 3 smallest subnormal numbers, or the three largest numbers, or whatever, would be extremely bad for allowing optimizations/algorithms/correctness checkers to reason about operations in the abstract.
https://m.youtube.com/watch?v=feJlRDLX0iQ