If you've taken any course that covers number systems, you've probably learned the "repeated multiplication" method for converting a decimal fraction to binary. Multiply by 2, record the digit before the decimal point, keep the remainder, repeat. It works. You can pass an exam with it. But it also feels a little like a magic trick — you follow the steps, you get the right answer, and you have no real intuition for why it works or why it sometimes never ends.
Here's the thought process that gave me that intuition, and where it eventually breaks.
The starting point: 0.25
Take 0.25. The standard method says: multiply by 2 repeatedly, record the integer parts.
0.25 × 2 = 0.50 → record 0
0.50 × 2 = 1.00 → record 1
Read top to bottom: 0.25 = 0.01 in binary. Correct, but mechanical.
Here's the alternative way I started thinking about it instead. 0.25 is just 1/4. And 4 is 2². So instead of multiplying repeatedly, what if I convert the numerator and denominator to binary separately, and treat the division as what it actually is — a division by a power of the base?
1 in binary is 1.
4 in binary is 100.
So 1/4 is 1 / 100 in binary. And dividing by 100 (in any base) doesn't require long division if 100 is a power of that base — it just shifts the point. In decimal, dividing by 100 shifts a decimal point two places left because 100 is 10². In binary, dividing by 100₂ (which is 4 in decimal) shifts the binary point two places left for exactly the same reason: 100₂ is 2².
Shift the point in "1." two places left: 0.01₂.
Same answer, but now you can see why it's the answer instead of just trusting the algorithm.
This isn't a coincidence — it's how place-value systems work
This generalizes. Any fraction a/2ⁿ can be converted by writing 'a' in binary and shifting the point n places. 1/2 → shift 1 place → 0.1₂. 1/8 → shift 3 places → 0.001₂. 3/16 → 3 is 11 in binary, shift 4 places → 0.0011₂.
It's the same logic as why dividing by 1000 in decimal is "free" (just move the point three places) — except in binary, the powers that are "free" are powers of 2, not powers of 10. This is also, not coincidentally, the entire basis of fixed-point arithmetic in embedded systems: when a microcontroller needs to represent a fraction without the overhead of a floating-point unit, it represents the value as an integer with an implicit binary point at a fixed position, and operations that would otherwise need division become bit-shifts. The "trick" above is a small, hand-worked version of that same idea.
Where it breaks
The shortcut depends entirely on the denominator being a power of 2. Try it on 0.2, which as a fraction is 1/5.
5 in binary is 101. 101 is not a power of 2 (it's 4 + 1, not a single power), so there's no clean shift available. To get 1/101₂ you actually have to do binary long division, and unlike 1/4, this one doesn't terminate. It repeats forever: 0.0011001100110011...
This is the same underlying reason 0.1 + 0.2 doesn't exactly equal 0.3 in most programming languages — 0.1 and 0.2 are not exactly representable in binary floating point, because their denominators (10 and 5) aren't powers of 2. It's not a bug in your code; it's a structural consequence of representing base-10 fractions in a base-2 system.
So the boundary is sharp: this shortcut is fast and exact for denominators of 2, 4, 8, 16, 32, and so on (equivalently, decimals like 0.5, 0.25, 0.125, 0.0625, 0.375). For anything else, you're back to repeated multiplication, and the result may never terminate.
The takeaway
None of this is a new method — it's a restatement of how positional number systems and fixed-point representation work, just arrived at by asking "what is this algorithm actually doing" instead of memorizing the steps. But that's worth writing down, because most people learn the multiplication method as a rote procedure and never connect it to the much more general (and much more useful) fact: in any base, dividing by a power of that base is just a point shift, and that single fact is also why certain "simple" decimal fractions can never be represented exactly in binary — a fact that quietly underlies one of the most common gotchas in floating-point programming.
Top comments (0)