News for hackers. Stuff that matters.
Re:Toward an API for the Real Numbers by lmm on Wednesday October 07, 2020 @03:05AM (#24705962)
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.

Re:Toward an API for the Real Numbers by taylodl on Wednesday October 07, 2020 @09:12AM (#24707793)
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.
Re:Toward an API for the Real Numbers by lmm on Wednesday October 07, 2020 @03:33PM (#24711789)
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.