Yeah, in general, this is a problem that people have spent a lot of time thinking about; while floating-point numbers can be finicky, they're what you have to work with if you have inputs at multiple scales.
(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.)
Not sure if this was written with AI assistance of not, but I've become allergic to linguistic triples as LLMs use them so much, reading "Same code. Same input. Different answer" makes me not want to read the rest.
If the original code was written in Rust, then I don't think the Rust compiler is allowed to do any of these "optimizations" of rewriting floating point expressions.
That's why they always teach: "never compare floats for equality."
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.
> It was IEEE 754 working as advertised. The standard pins down the storage format. It does not pin down behavior.
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.
Once I understood that floating point arithmetic was just a fast useful approximation of actual numbers, it changed my thinking of when to use them.
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.
13 comments
[ 2.5 ms ] story [ 37.3 ms ] thread(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...
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.
https://www.johnbcoughlin.com/posts/floating-point-axiom/
IEEE 754 absolutely does pin down behavior.
Ah yes -ffast-math, also known as -fincorrect-math
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.
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.