Why 0.1 + 0.2 Gives 0.30000000000000004 – Inside 64‑bit Floating‑Point Math

Exact binary representation of 0.1 and 0.2

In a 64‑bit IEEE‑754 double the decimal literals 0.1 and 0.2 are stored as the nearest representable binary fractions. Using Python’s format specifier we can see the full 80‑digit decimal expansion of the stored values:

>> f"{0.1:.80f}"
'0.10000000000000000555111512312578270211815834045410156250000000000000000000000000'
>>> f"{0.2:.80f}"
'0.20000000000000001110223024625156540423631668090820312500000000000000000000000000'

Both numbers share the same 52‑bit mantissa ( 2702159776422298); the only difference is the exponent (‑4 for 0.1, ‑3 for 0.2 after bias removal).

Exact decimal addition

Treating the fractional parts as integers (by multiplying with 2⁵⁶) gives the exact integer sum:

1000000000000000055511151231257827021181583404541015625 +
2000000000000000111022302462515654042363166809082031250 =
3000000000000000166533453693773481063544750213623046875

Dividing by the common scaling factor 2⁽⁵²+⁴⁾ converts the integer back to a real number, but the result has more than 52 mantissa bits and therefore is not a valid double.

Rounding to the nearest representable double

The two IEEE‑754 numbers that bracket the exact sum are:

0.299999999999999988897769753748434595763683319091796875
0.3000000000000000444089209850062616169452667236328125

The exact sum lies exactly halfway between them. IEEE‑754 specifies “round‑to‑nearest, ties‑to‑even”, so the value whose least‑significant mantissa bit is even is chosen – the second one, which is displayed as 0.30000000000000004.

Verification with struct and math.nextafter

>> import struct, math
>>> struct.pack('!d', 0.3)
b'?\xd3333333'
>>> struct.unpack('!d', b'?\xd3333334')[0]
0.30000000000000004
>>> math.nextafter(0.3, math.inf)
0.30000000000000004

The byte pattern b'?\xd3333334' corresponds to the next double after 0.3, confirming the rounding result.

IEEE‑754 double layout

A double consists of:

1‑bit sign

11‑bit exponent (biased by 1023)

52‑bit mantissa (implicit leading 1 for normal numbers)

The value is computed as:

value = (-1)**sign * 2**(exponent-1023) * (1 + mantissa/2**52)

Python helpers to extract the raw fields:

def get_exponent(f):
    b = struct.pack('!d', f)
    return int.from_bytes(b, 'big') >> 52 & 0x7FF

def get_mantissa(f):
    b = struct.pack('!d', f)
    return int.from_bytes(b, 'big') & ((1 << 52) - 1)

Applying them to 0.1 and 0.2 yields exponents -4 and -3 (after subtracting the bias) and the identical mantissa 2702159776422298.

Why printing shows a short decimal

When a language prints a floating‑point number it chooses the shortest decimal string that rounds back to the same binary value (the “shortest‑round‑trip” property). Both Python and most other languages therefore print 0.3 for the stored value 0.299999999999999988… because that short string maps back to the same double.

Cross‑language note (PHP)

PHP uses the same IEEE‑754 arithmetic. Its default string conversion also applies the shortest‑round‑trip rule, so echo 0.1+0.2; prints 0.3. The underlying binary result is identical to Python’s 0.30000000000000004 and can be observed with printf('%.17g', 0.1+0.2);.

Illustration of the exponent‑mantissa formula