Usually, if you know enough about your algorithms to select an appropriate float alternative, you also know enough to fix your float code and that's what you should actually do.
That said, some of these aren't alternatives. Symbolic computation is a different thing entirely. Interval arithmetic can be built atop floats (e.g. IEEE-1788) and has its own zoo of unintuitive behaviors. BCD is better called a historical artifact than an alternative these days.
It's really just rationals and decimal floats in this list, which probably don't solve the issues you have if you're considering float alternatives.
You can't "fix" floating point code if you are looking for deterministic answers. You just have to use other data types to handle money or complex mathematical operations like 0.2+0.1, no ifs and buts.
> Floating point is deterministic, what are you talking about?
Order of operations can change a result, for example. I suspect you mean that the algorithm never changes. While op means that mathematical operations which most folks would expect to be reliable are not.
There are enough problems for a 44 page paper titled "What Every Computer Scientist Should Know About Floating-Point Arithmetic"[1] I don't quibble on the language because I know what people mean.
Most folks won't encounter most of the issues, generally. But expose your code to a large enough dataset, or be like me and write a CAD/CAM system with motion control and experience most of them.
That (no doubt excellent, but) technical PDF is overselling the problem somewhat, when what every dev needs to know is better represented by a friendlier summary like <a href="https://floating-point-gui.de/" rel="nofollow">https://floating-point-gui.de/
That's a great resource as well. Targeted at developers, rather than computer scientists. Same observations, different target audiences and expectations. You're probably right that the more practical reference targeted at developers is more useful here. My references are full of the academic papers because of my CAD work.
AlotOfReading · · focus · HN ↗
That said, some of these aren't alternatives. Symbolic computation is a different thing entirely. Interval arithmetic can be built atop floats (e.g. IEEE-1788) and has its own zoo of unintuitive behaviors. BCD is better called a historical artifact than an alternative these days.
It's really just rationals and decimal floats in this list, which probably don't solve the issues you have if you're considering float alternatives.
TZubiri · · focus · HN ↗
messe · · focus · HN ↗
> You just have to use other data types to handle money or complex mathematical operations like 0.2+0.1
Such as... decimal floating point.
timschmidt · · focus · HN ↗
Order of operations can change a result, for example. I suspect you mean that the algorithm never changes. While op means that mathematical operations which most folks would expect to be reliable are not.
messe · · focus · HN ↗
timschmidt · · focus · HN ↗
Most folks won't encounter most of the issues, generally. But expose your code to a large enough dataset, or be like me and write a CAD/CAM system with motion control and experience most of them.
That's why I wrote hyperreal[2]
1: <a href="https://www.cs.tufts.edu/cs/40/docs/WhatEveryComputerScientistShouldKnowAboutFloatingPointArithmetic.pdf" rel="nofollow">https://www.cs.tufts.edu/cs/40/docs/WhatEveryComputerScienti...
2: <a href="https://github.com/timschmidt/hyperreal" rel="nofollow">https://github.com/timschmidt/hyperreal
dspillett · · focus · HN ↗
timschmidt · · focus · HN ↗
dspillett · · focus · HN ↗
Sorry, yes, I probably should have worded that in a way that made the distinction more obvious.