Adding Floating-Point Decimals for Fun and Profit

The piece examines why decimal arithmetic with IEEE double-precision floats often behaves oddly - yet sometimes looks perfectly fine - when adding familiar amounts like cents. It explains floating-point representation (1 sign bit, 11 exponent bits, 52 fraction bits), the notion of ulp (unit in the last place), and how arithmetic proceeds by forming an exact sum and then rounding to the nearest representable float (ties to even). The canonical example 0.1 + 0.2 is worked through: each decimal is converted to the nearest float, their exact sum lies exactly between two floats so round-to-even yields a result that prints as 0.30000000000000004 under conventional decimal-conversion rules formalized by Steele and White, which demand round-tripability, shortest representation, and closeness.

The analysis generalizes to summing any two positive decimal multiples of 0.01 under a practical bound (below about 70 trillion), defining Δ = float(float(a)+float(b)) − float(a+b) and expressing it in terms of error(x)=float(x)−x. Each error term is bounded by half an ulp, so Δ is tightly constrained and often zero at typical magnitudes. Numerical techniques (Veltkamp splitting, Dekker product) are presented to compute or bound the error in practice, with code sketches. Practical takeaway: IEEE doubles in most languages behave predictably; rounding modes and the decimal-printing algorithm determine whether tiny representation errors become visible, and straightforward splitting methods let you detect or correct them when necessary.