Floats Don't Agree with Themselves(docs.merca.earth) |
Floats Don't Agree with Themselves(docs.merca.earth) |
We seem to have lost the war for people to find their own voice, the AI articles are getting widely upvoted, and people pointing out they are AI are no longer getting traction, people don't seem to care.
IEEE 754 absolutely does pin down behavior.
That being said, many hardware instruction does not follow strict IEEE 754 behavior.
Visualizing of floats as a arbitrary sample of numbers along the number line that you were allowed to choose from is a good way to figure out whether or not you should be using them.
Much like financial calculations, for this use case, exact representations of inputs are needed. An approximation of what the input might be isn’t useful.
One thing if you want point out though: there is a difference between reproduceability and accuracy.
The Java Virtual Machine (>=17, or strictfp) on every processor arch, OS, glibc, etc guarantees strict reproduceability for basic operations on floats.
some operations Math (pow, cos, log, etc) package are allowed to differ within a tiny precision window.
If you need absolute reproduceability, you can use StrictMath, which gives us an interesting property for a library like this: you could use floats, and it would be a bit reproducible on every platform and software stack combination and be deterministic, everywhere.
It would not have absolute integer math accuracy however. Whether that is still useful is up to you.
cross_sign(A, B, C)
The main caveat is that on x86 targets without SSE2, LLVM is deeply wired to use the x87 instructions without attempting to emulate the IEEE overflow/underflow behavior [1]. So perhaps it could be possible to exhibit a discrepancy, but only by compiling for i586 and an ancient target-cpu. It's very doubtful that this was the cause of the original client vs. server issue in TFA's introduction.
[0] https://rust-lang.github.io/rfcs/3514-float-semantics.html
(Meanwhile, I wonder why it's a fair bit harder to look up Ozaki et al.'s optimized version [0] compared to Shewchuk's original paper [1], unless perhaps later authors have found it to be no improvement at all.)
[0] https://www.tuhh.de/ti3/paper/rump/OzBueOgOiRu15.pdf
[1] https://people.eecs.berkeley.edu/~jrs/papers/robust-predicat...
ARM and WASM dropped it for a reason, and more bits would not help anyway, a sign is one bit, any rounding step that disagrees at the last bit flips it
Huh? This is just false, isn't it? AFAIK, it pins down behavior, and the differences come from things like changing the order of operations (i.e. accumulating rounding error in a different order). I'm not an expert, though.
(And NaN payloads in general are a mess across platforms and ABIs, but that can be solved by treating all NaNs as identical.)
Ah yes -ffast-math, also known as -fincorrect-math
But no, instead it is a fat shotgun.
Or maybe they don't teach that anymore, I dunno.
See link for the Fundamental Axiom of Floating Point Arithmetic: All floating point arithmetic operations are exact up to a relative error of epsilon_machine.