If they shouldn't be IEEE 754 then what would you use instead? IEEE 754 exists because a lot of smart people put a lot of thought into what the best floating point representation should be. Then the hardware folks put a lot of work into making it fast and accurate.
IEEE 754 is designed for scientific computation and simulation. And it's very good for that. However it's terrible for representing decimal numbers and fractions. You end up with the exact problems described in the article.
It's kind of a problem since most programmers aren't writing programs to do scientific/modeling. They're writing programs that are doing decimal math and currency where IEEE 754 is inappropriate.
I ask again: what would you use instead? The industry has decided that IEEE 754 is the best all-around compromise, and everything is optimized for that case. Most programs aren't doing "decimal math", but programmer expectations are shaped by that since that's what they've used all their life.
And I'll repeat what the parent said, again: decimal math.
>Most programs aren't doing "decimal math"
And yet they do. Most programs do decimal math with floats, either because the programmers don't know that's not a thing (and consider floats the same as decimals), or because the language doesn't give them anything else (e.g. Javascript up until recently), or because workarounds are cumbersome (e.g. representing as fractions or working with integers for money with a scale factor and downscaling in the end, etc).
But in almost all programs, the kind of math the program needs to be done, from money handling, to estimating distances, to layout, etc are better done as decimal.
Floating point don't represent a way to solve any kind of actual problem, except the problem of speed and memory representation. So their use is because of computer constraints, not because the problem domain requires floating calculations.
The only point I'll concede is monetary calculations. Estimating distances? Layout? I can't see how the difference between decimal and binary changes anything.
Decimal math isn't built into most of the languages or processors we use, so that's why I keep asking what you'll use. It's a kind of hand-wavy response. You'll need to seek out an appropriate library and use it consistently, which is a lot more trouble than just using the built-in IEEE. Not impossible, just usually more trouble than it's worth.
>Estimating distances? Layout? I can't see how the difference between decimal and binary changes anything.
Whether it changes everything is neither here not there.
It might still result in the same output (e.g. the lack of precision might not matter for layout purposes), but there's absolutely no domain need to do the calculations in FP except for performance or lack of a better number type in the language.
In all of these cases, the exact match would be better than lack of precision, aside from the performance and similar (memory, etc) costs.
That is, if decimal was computing-wise as fast and as available as FP, there would be absolutely no reason to use FP. It's not a choice of mathematical need (e.g. not imposed by the calculation) but a choice of computing constraints.
>Decimal math isn't built into most of the languages or processors we use, so that's why I keep asking what you'll use.
In my experience many languages have it (C#, Java, Python, Javascript is getting it, etc) and people don't use it.
And in most cases, being in the processors wouldn't matter - we use FP for all kinds of non-critical performance calculations, not because it's needed for the speedup, but because it's there.
When there is indeed a need for the CPU-support, I'd use FP myself, sure. But not in most other cases, and absolutely not for money and other cases where precision matters (but people still use FP).
I hope you noticed that IEEE 754 merged DFP support in 2008.... Which means its actually quite good at base 10 if you have a machine/compiler that supports it.
reply