Floats Don't Agree with Themselves

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.

This article is full of LLM-induced inconsistency.

That being said, many hardware instruction does not follow strict IEEE 754 behavior.

It makes sense in certain contexts, but it is batshit insane that it is enabled on a program (including any linked stuff) level. It would have made sense as numbers with separate types or perhaps even if you marked a region in code and it applied only to code in that region. Then the consequences of enabling it could be understood in ways that could be safe and usable (eg enabling it for a hot loop where the numerical ranges are well defined and safe in context).

But no, instead it is a fat shotgun.