News for hackers. Stuff that matters.
Re:Beware of Fast-Math by eapriv on Saturday May 31, 2025 @10:06AM (#44144362)
Why is it not commutative?
Re:Beware of Fast-Math by layer8 on Saturday May 31, 2025 @10:40AM (#44144586)
It actually is commutative according to IEEE-754, except that in the case of a NaN result you might get a different NaN representation.
Re:Beware of Fast-Math by adgjlsfhk1 on Saturday May 31, 2025 @06:03PM (#44147229)
having multiple NaNs and no spec for how they should behave feels like such an unforced error to me
Re:Beware of Fast-Math by layer8 on Saturday May 31, 2025 @08:59PM (#44147950)
For mathematical use, NaN payloads shouldn’t matter, and behave identically (aside from quiet vs. signaling NaNs). It also doesn’t matter for equality comparison, because NaNs always compare unequal.
Re:Beware of Fast-Math by adgjlsfhk1 on Sunday June 01, 2025 @08:57AM (#44150546)
from the user perspective it's not too bad, but from the compiler perspective it is. The result of this is that LLVM has decided that trying to figure out which nan you got (e.g. by casting to an Int and comparing) is UB, which means pretty much every floating point operation becomes non-deterministic.

This also adds extra complexity to the CPU. you need special hardware for == rather than just using the perfectly good integer unit, and every fpu operation needs to devote a bunch of transistors to handling this nonsense that buys the user absolutely nothing.

there are definitely things to criticize about the design of Posits, but the thing they 100% get right is having a single NaN and sane ordering semantics