Why 0.1 + 0.2 Isn't 0.3: The Hidden Pattern in Floating-Point Addition
Adding Floating-Point Decimals for Fun and Profit
Floating-point addition of decimals like 0.1 + 0.2 famously yields 0.30000000000000004, but the errors aren't random. By analyzing the ulp (unit in the last place) and the error function, the author shows that summing two multiples of 0.01 up to 1.00 produces a striking checkerboard pattern. The result can be at most one ulp off, and the pattern arises from interference between three copies of the error function. A deep dive into IEEE double-precision arithmetic and the Steele-White algorithm for decimal conversion.
Famously, with IEEE double-precision floats, 0.1 + 0.2 is not 0.3, but rather, 0.30000000000000004.
- sieve
Accounting has the concept of materiality. But you still want the figures to tally to the last cent.
One way to do this is to separate the computation/storage and presentation layer: use integers to store values as cents for computation/storage and only convert to dollars+cents on display. But then someone might suddenly demand three digits after the decimal point and you cannot go about changing every stored value just because the logic changed in one part of the application. So, using decimals is the safer choice.
I prefer integers for my plain text ledger software though because the format is in my control.
- amelius
> Many people know that you shouldn’t do decimal calculations, such as those involving U.S. dollars and cents, with the floating-point numbers in most programming languages. This is because decimal numbers can’t be expressed exactly as such floating-point numbers, so you will encounter rounding errors.
Why not, rounding to the nearest cent is going to be much less precise for any realistic amount of dollars when using 64 bit floats (the type of float Javascript uses in every browser).
- sobriquet9
Besides Python’s fractions, there are also constructive reals, exemplified by Android calculator where you can swipe any answer to get as many digits as you want.