Number Base Converter

Changing base changes which fractions are exact

Converting a whole number between bases loses nothing — 255 and FF are the same number written twice. Fractions are a different matter. Whether 1/q can be written with finitely many digits depends on the base you write it in, and the rule is exact: 1/q terminates in base b if and only if every prime factor of q also divides b. Nothing about the size of q matters, only which primes are in it.

That rule is easy to state and easy to doubt, so it is worth checking against the thing it predicts. Expanding 1/2 through 1/60 digit by digit in nine different bases and asking whether the digits ever stop gives 531 cases; the prime-factor rule agrees with the actual expansion on every one of them.

Two things fall out of that table. The first is that a prime base is the worst possible choice: base two can only write powers of two exactly, so of the ninety-nine fractions 1/2 through 1/100 it manages 6. Base ten manages 14, because it has two primes to work with rather than one. The second is that only the distinct primes count — base four behaves exactly like base two and base twenty exactly like base ten, because squaring a base adds no new primes to divide out.

This is the whole of the duodecimal argument in one line. Twelve is 2 · 2 · 3, so it handles thirds and quarters and sixths, and it writes 19 of those ninety-nine exactly against ten's 14. Sixty, which is 2 · 2 · 3 · 5, reaches 33 — which is a reasonable guess at why an hour still has sixty minutes four thousand years after somebody picked the number.

Which is why 0.1 + 0.2 is not 0.3

Ten has the prime factor 5. Two does not. So by the rule above, a tenth cannot be written exactly in binary — and a computer storing numbers in binary cannot store 0.1. The expansion is 0.000110011001100110011001… — a leading zero and then 0011 forever, in the same way a third repeats 3 forever in decimal. Neither is a flaw in the number; both are a mismatch between the number and the base.

What a double-precision float actually holds when you write 0.1 is the nearest value it can represent, which is 0.1000000000000000055511151231257827 — slightly too big. Add the similarly-inexact 0.2 and the errors do not cancel, so the sum misses 0.3 by a few parts in 10¹⁷ and 0.1 + 0.2 === 0.3 is false in every language that uses these floats, which is nearly all of them.

The useful corollary is that the fix is never more precision. Adding digits to a repeating expansion gets you closer and never gets you there. If a value has to be exact — money, most obviously — the answer is to change the representation rather than the precision: store cents as integers, or use a decimal type that carries the base with it. That is the same move as writing 1/3 rather than 0.333, and for the same reason.