Why does 0.1 + 0.2 = 0.30000000000000004?

Type 0.1 + 0.2 into a Python prompt, a JavaScript console, a spreadsheet or most phone calculators, and a surprising number of them will hand you 0.30000000000000004. It is one of the most searched questions in programming, and the answer has nothing to do with bad code.

One third, but in binary

Write 1/3 as a decimal and you get 0.3333… forever. You have to stop somewhere, and the moment you stop, you are slightly wrong. Nothing is broken. The base you chose simply cannot express that fraction in a finite number of digits.

Binary has the same problem, just with different fractions. A binary fraction can only end cleanly if its denominator is a power of two. One half is fine. One quarter is fine. One tenth is not, because 10 = 2 × 5, and that 5 has no home in base two. So 0.1 in binary repeats forever:

0.1  =  0.0001100110011001100110011... (repeating)
0.2  =  0.0011001100110011001100110... (repeating)

Your computer stores numbers in 64 bits, so it stops after 53 significant bits and rounds. What it actually holds is not 0.1 but something a hair away from it:

0.1 → 0.1000000000000000055511151231257827021181583404541015625
0.2 → 0.200000000000000011102230246251565404236316680908203125

Two small errors, one visible one

Add those two real stored values and the exact sum lands a tiny bit above 0.3. The machine then rounds that sum to the nearest representable number, and the nearest one is not the same one it would pick for the literal 0.3. So the comparison fails and the extra digits surface:

0.1 + 0.2 = 0.3000000000000000444089209850062616169452667236328125
0.3       = 0.299999999999999988897769753748434595763683319091796875

0.1 + 0.2 == 0.3   →  false

Most of the time you never see this, because the display rounds to a handful of digits and hides it. The error only becomes visible when something prints the full value, or when you compare two numbers for equality, or when you add thousands of small amounts and the rounding accumulates into real money.

Where it actually bites

The fix: stop using binary for decimals

Floating point is not a mistake. It is a deliberate trade: enormous range and speed in exchange for a small, bounded error. For physics and graphics that trade is correct. For a calculator, where a human reads every digit and expects the arithmetic they learned at school, it is the wrong trade.

The alternative is exact rational arithmetic. Instead of converting 0.1 to binary, keep it as the fraction it is:

0.1  →  1/10        exactly
0.2  →  2/10        exactly
sum  →  1/10 + 2/10 = 3/10  =  0.3   exactly

No conversion, no rounding, no error. The cost is speed and memory, because the numerator and denominator can grow large. On a phone doing one calculation at a time, nobody notices that cost.

This is also why the same engine can show you 2 3/4 instead of 2.75: if the number was a fraction the whole time, keeping it in fractional form is free. A binary float has already thrown that away.

How to check your own calculator

Type 0.1 + 0.2. If you get 0.3, either the app uses exact arithmetic, or it is rounding the display and hiding the drift. To tell the two apart, try 0.1 + 0.2 - 0.3. An exact calculator returns 0. A floating point one returns 5.551115123125783e-17, or a confident looking 0 that is really that number with the digits cut off.

Prism does the exact version

Prism Calculator computes with exact rational arithmetic, so 0.1 + 0.2 is 0.3 and fractions stay fractions. Free on the App Store. See the app.