0.1 + 0.2 and someone’s salary

Here is a program that should print true:

double phi = (1 + sqrt(5)) / 2;
printf(1 / phi == phi - 1 ? "true" : "false");   /* false */

The golden ratio satisfies 1/φ = φ − 1 exactly. The computer disagrees in the sixteenth decimal, because the two sides reach the same number through different roundings. In competitive programming the fix is a reflex: compare with a tolerance, fabs(x - y) < 1e-9, and move on to the next problem. I did that for years.

To see why, look at what a double actually holds. 0.1 has no exact binary form, so the machine stores the closest value it can.

Fig. 1 — What a double actually storesIEEE 754 · 64 bits

Loading interactive figure…

Static version: 0.1 is stored as 0.1000000000000000055511151231257827…

Then the numbers became salaries. Payroll across countries is additions, rates and roundings, millions of times a month, in currencies that do not even agree on how many decimals they have: the Japanese yen has none, the Kuwaiti dinar has three. Every rounding lands in someone’s account, and the totals must reconcile to the last unit. The scenario below is generic, not any company’s system. Add the same amount to a running total, payslip after payslip.

Fig. 2 — Add it up, N timesfloat vs integer minor units

Loading interactive figure…

Static version: 0.10 added 1,000,000 times in float is 100000.00000133288; in integer cents, exactly 100,000.00.

The drift is a tiny fraction of a cent. Round the total and it even looks right, which is the trap. The equality check fails, the reconciliation job raises an alarm, and someone adds an epsilon to silence it. From then on the epsilon is policy.

Where the cents really go

The money that actually goes missing comes from somewhere else: applying a rate, an FX conversion or an uplift, and rounding every line.

Fig. 3 — Apply a rate, round to the cent100,000 lines · 0.01 to 1,000.00 · round half up

Loading interactive figure…

Static version: at rate 1.15, 2,376 of 100,000 lines are off by a cent with floats; with integer cents, none.

At a rate of 1.15, 2,376 of 100,000 lines round to the wrong cent with floating point. With integer cents and a decimal rate, none do. An epsilon cannot fix that, because nothing is “close enough” about a cent paid to the wrong person.

The fix is a representation, not a comparison:

1. Store money as an integer count of minor units plus a currency, and take the number of decimals from the currency (ISO 4217), never from a global “2”.
2. Do rate math in a decimal type, choose one rounding rule (half-up or half-even), write it down, apply it once at a defined step, and property-test it against exact arithmetic.
3. Treat reconciliation as equality. If totals only match with an epsilon, the bug is upstream.