3 ms·

Sign bits of NaN is one of the dumbest parts of the 754 standard. 6.3 specifies that "the standard does not interpret the sign bit of a NaN" and then the very n

Sign bits of NaN is one of the dumbest parts of the 754 standard. 6.3 specifies that "the standard does not interpret the sign bit of a NaN" and then the very next sentence lists four cases where the sign bit of NaN has semantic meaning.

adgjlsfhk1 4y ago
really all of the NaN behavior is really dumb. "we gave you enough different NaNs to uniquely represent every grain of sand on the planet uniquely" how does math work on them? "we have no idea" how do we tell what type of nan we have? "we have no idea" what should these bajillion values represent? "I don't know, probably something" the fact that they didn't just make there be a single NaN and make it equal to itself (and while you're at it make it so the real numbers have a total ordering)
- kryptiskt 4y ago
  But in the end we found a great use case for all those NaN values because NaN-boxing is awesome.
  - adgjlsfhk1 4y ago
    except that it breaks on processors that propagate nan bits differently (e.g. m1)
- jcranmer 4y ago
  > how does math work on them? For almost all operations, if any input is a NaN, the result is a NaN. It's pretty well-specified by IEEE 754, the only thing that isn't is what the payload is, but there's no general expectation that the payload is preserved through computation. > how do we tell what type of nan we have? `getpayload()` > what should these bajillion values represent? Diagnostic information that tells you which operation caused the NaN in the first place. (This is Kahan's standard argument for why having many NaNs can be useful.) > the fact that they didn't just make there be a single NaN What's the alternative? You'd either have to have lots of illegal floating point values, or you'd have to make the number of finite floating-point numbers with the highest exponent value slightly smaller than for all other exponent values, which complicates a good deal of numerical analysis. > make it equal to itself Yeah, this is the big, nasty mistake of IEEE 754. > and while you're at it make it so the real numbers have a total ordering There is a totalOrder predicate specified by IEEE 754. Representing floating-point comparisons as a partial order is arguably better than giving it a total order, but the lack of reflexivity of equals makes the existing predicates not a partial order.

adgjlsfhk1 4y ago

really all of the NaN behavior is really dumb. "we gave you enough different NaNs to uniquely represent every grain of sand on the planet uniquely" how does math work on them? "we have no idea" how do we tell what type of nan we have? "we have no idea" what should these bajillion values represent? "I don't know, probably something" the fact that they didn't just make there be a single NaN and make it equal to itself (and while you're at it make it so the real numbers have a total ordering)

kryptiskt 4y ago
But in the end we found a great use case for all those NaN values because NaN-boxing is awesome.
- adgjlsfhk1 4y ago
  except that it breaks on processors that propagate nan bits differently (e.g. m1)
jcranmer 4y ago
> how does math work on them? For almost all operations, if any input is a NaN, the result is a NaN. It's pretty well-specified by IEEE 754, the only thing that isn't is what the payload is, but there's no general expectation that the payload is preserved through computation. > how do we tell what type of nan we have? `getpayload()` > what should these bajillion values represent? Diagnostic information that tells you which operation caused the NaN in the first place. (This is Kahan's standard argument for why having many NaNs can be useful.) > the fact that they didn't just make there be a single NaN What's the alternative? You'd either have to have lots of illegal floating point values, or you'd have to make the number of finite floating-point numbers with the highest exponent value slightly smaller than for all other exponent values, which complicates a good deal of numerical analysis. > make it equal to itself Yeah, this is the big, nasty mistake of IEEE 754. > and while you're at it make it so the real numbers have a total ordering There is a totalOrder predicate specified by IEEE 754. Representing floating-point comparisons as a partial order is arguably better than giving it a total order, but the lack of reflexivity of equals makes the existing predicates not a partial order.