Floating-Point Arithmetic

0.1 + 0.2 == 0.3 returns False in almost every mainstream programming language. Not because of a bug — because 0.1 cannot be written exactly in the binary format computers use for fractional numbers, in the same way $1/3$ cannot be written exactly in decimal. It's not an edge case you can code around once; it's a permanent property of how the number is stored, and it has to be understood, not patched.

The idea: a ruler with finite ticks

Think of a floating-point number as a ruler that isn't infinitely fine. It has a fixed number of tick marks, and those ticks get closer together near zero and farther apart for huge numbers, but there is always a gap between one representable value and the next. Any real number that doesn't land exactly on a tick gets rounded to the nearest one. The standard format, IEEE 754 double precision (the float64 used almost everywhere by default), splits its 64 bits into three parts: 1 bit for the sign (positive or negative), 11 bits for the exponent (how far to shift the point — this is what lets the ruler cover both tiny and enormous numbers), and 52 bits for the mantissa (the significant digits themselves, giving about 15-17 correct decimal digits).

The exponent is exactly why the ticks aren't evenly spaced: a fixed number of mantissa bits covers a relative range near any given magnitude, so numbers near 1.0 have ticks about $2^{-52} \approx 2.2 \times 10^{-16}$ apart, while numbers near 1,000,000 have ticks roughly a million times coarser. This is a scale-relative error, not an absolute one — the same reason a ruler marked in centimeters is "exact enough" for a room but useless for a chip.

Worked example: why 0.1 + 0.2 isn't 0.3

0.1 in binary is a repeating fraction, just like $1/3$ is a repeating decimal (0.3333...). Written in binary, $0.1 = 0.0001100110011\overline{0011}_2$, forever repeating. With only 52 mantissa bits, the stored value is truncated and rounded to the nearest representable tick, which is very slightly above the true 0.1 — approximately $0.1000000000000000055511151231257827$. Likewise, the stored 0.2 is approximately $0.200000000000000011102230246251565$, also slightly above true 0.2.

Add the two stored (already-rounded) values: the sum comes out to approximately $0.3000000000000000444089209850062616$, which itself gets rounded to the nearest representable tick — and that nearest tick is not the same tick that 0.3 typed directly rounds to. Print both with enough digits and the mismatch is visible directly:

>>> 0.1 + 0.2
0.30000000000000004
>>> 0.1 + 0.2 == 0.3
False
>>> abs((0.1 + 0.2) - 0.3) < 1e-9
True

The third line is the standard fix: never compare floats with ==; compare within a small tolerance (an absolute or relative epsilon appropriate to the magnitudes involved).

Worked example: error accumulation in a running sum

The single-comparison error above is tiny (about $4\times10^{-17}$), but repeated arithmetic can compound it. Summing the same value 10,000 times in a naive loop, versus using a technique that tracks the rounding error separately (Kahan summation), shows the gap:

x = 0.1
total = 0.0
for _ in range(10_000):
    total += x
print(total)          # 999.9999999999062  -- not exactly 1000.0
print(total - 1000.0) # -9.37...e-11

Trace why: each += rounds to the nearest representable tick, and because 0.1 itself was already an approximation, each addition's rounding error doesn't average out to zero — it drifts, because the running total's magnitude keeps growing while each individual addend's contribution to the last bit gets relatively smaller as the total grows (adding a small number to a much larger one loses some of the small number's precision, since the sum has to round to the larger number's coarser tick spacing). Over 10,000 additions the drift reaches about $10^{-10}$ — small here, but the same mechanism is what makes naive volatility or P&L accumulators drift measurably over a full trading day of tick-by-tick updates if nothing resets or corrects them.

Where this shows up

In a quant-dev interview, this appears as "why doesn't 0.1 + 0.2 == 0.3" or "how would you compare two computed Sharpe ratios for equality," and the expected answer is relative-tolerance comparison plus a one-line explanation of binary representation, not "computers are just imprecise." In production, floating-point behavior drives real design decisions: prices are often stored as integer ticks (cents, or an exchange's minimum price increment) rather than floats specifically to get exact arithmetic and exact equality checks; P&L and risk aggregation code sums in a fixed, deterministic order and sometimes uses higher-precision (float64 over float32, or compensated summation) accumulators specifically to bound the drift traced above; and cross-language or cross-system reconciliation breaks that look like "off by a rounding error" are, more often than not, exactly this.