Re:Toward an API for the Real Numbers
by taylodl on Tuesday October 06, 2020 @06:06PM
(#24702863)
IEEE 754. If you're going to do any serious computation in floating point, serious meaning people's lives are going to depend on the outcome or a lot of money is on the line, then you MUST know what you're doing. We have standards in place so people can learn it, people creating math libraries can adhere to it, and those creating these kinds of applications can have confidence that things are going to work. I'm sorry addition isn't commutative, there are known ways for dealing with it. I took two courses in Numerical Computing in college. Trust me, the people working in this space are serious, and really, there's a few basic rules of the road you need to learn and you're on your way.
[ Parent
| on HN ]
> I'm sorry addition isn't commutative...
My understanding is that in IEEE 754 compliant implementations of floating-point arithmetic, commutativity over "+" holds but not associativity. (With the possible exception to commutativity for the NaNs, though I don't remember offhand whether this caveat is necessary).
You are correct. It's associativity that doesn't hold, not commutativity. It really throws people off.
It's a lot more than "a few basic rules of the road". Why squander your attention budget on a numeric type with so many caveats and edge cases? What do you gain from it? If you actually need the performance of IEEE 754, then sure, use it, and have fun debugging all of the problems it has. But it's an extremely poor default for general-purpose programming.
Re:Toward an API for the Real Numbers
by otabdeveloper4 on Wednesday October 07, 2020 @06:30AM
(#24706875)
I disagree. IEEE 754 is a fantastic solution if you want a no-brainer plug-and-play approximation of the real numbers.
Most people who complain really just want a rational number type.
Immaturity - it's the plague of our industry. The experts in floating point arithmetic, each having years of real-world experience, came together and hashed-out a standard embodying their collective experience. Yes, it's complicated. Yes, you need to learn it. No, you're highly unlikely to come up with anything better. Moreover, even if you did come up with something better it WILL have bugs, there WILL be edge cases that catch everyone by surprise. So instead of using a standard having 35 years worth of collective experience, whose edge cases are well-known, whose implementation is literally etched in silicon, and thousands upon thousands of libraries utilizing it - we'd rather start over and re-invent. That way we can spend the next 35 years uncovering a whole new and unknown set of issues. Sigh.
A cultish devotion to "performance" and a refusal to revisit tradeoffs that were for hardware literally 10 million times slower than today's systems is the real plague of our industry. Yes, IEEE 754 was a towering technical achievement in its day (though its use is marred in practice by an industry that implemented only the most problematic of its rounding modes and ignored the trapping mode that should have been the default as soon as hardware performance improved a little), no-one's denying that. But it's got a lot of sharp edges (that were necessary at the time; indeed IEEE 754 makes significant performance compromises compared to e.g. Cray non-754 floating point modes) that a mature industry would not expose by default.