Adding Floating-Point Decimals for Fun and Profit
A mathematical analysis of floating-point addition errors for decimal numbers, deriving error bounds and exploring error-free transformation algorithms.
read it Offers a rigorous mathematical breakdown of floating-point error propagation accompanied by practical error-free transformation code.
summary
The author investigates the rounding errors that occur when adding decimal numbers using IEEE double-precision floats, moving beyond standard warnings to mathematically model the error function. By bounding the differences between exact sums and floating-point operations, the post explains the periodic patterns visible in error heatmaps. An appendix details practical error-free transformations like Dekker products that allow computing exact floating-point errors without precision loss. The deep dive illuminates how floating-point arithmetic behaves under the hood.
key points
- Floating-point addition errors for decimal amounts under $70 trillion are mathematically bound to at most 1 ulp (unit in the last place).
- Visual heatmaps of decimal addition errors reveal periodic checkerboard patterns caused by the interaction of binary exponents and decimal fractions.
- Error-free transformation algorithms like 2Sum and Dekker products enable computing exact floating-point errors without leaving floating-point arithmetic.
who should read it
Software engineers and systems programmers interested in numerical analysis and floating-point internals.
discussion positive
consensus
Commenters agree that while the mathematical analysis is fascinating, practical financial software should avoid binary floats entirely in favor of integers representing cents or dedicated decimal types to prevent subtle comparison bugs.
pushback
A minority argues that floating-point errors in financial calculations are often below the materiality threshold, or that changing data types doesn't replace proper numerical analysis.
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 …
It provides a clear architectural perspective on why integers or decimals are preferred over floats for balancing computation, storage, and presentation layers in financial systems.
Generated by an LLM from the article and thread. Check the sources before relying on it.