When Using Bits to Represent Fractions of a Number Can You Create All Possible Fractions? No, and Here Is Exactly Why

No. When you use bits to represent fractions of a number, you can create only the fractions whose denominators are powers of two, such as 1/2, 3/4, and 5/8. Values like 1/3 or 1/10 cannot be stored exactly in a fixed number of binary bits. They are rounded to the nearest representable value, so the set of exact fractions is finite and sparse.

This answer holds whether you mean fixed-point fractions or floating-point fractions. Both systems store numbers as sums of powers of two. That design makes many everyday decimals impossible to represent exactly, and it explains why 0.1 + 0.2 sometimes prints as 0.30000000000000004.

The binary place-value mechanism

A binary fraction is a sum of powers of two, just as a decimal fraction is a sum of powers of ten. In decimal, 0.375 means 3 tenths plus 7 hundredths plus 5 thousandths. In binary, the same value is 0.011, meaning 0 halves plus 1 quarter plus 1 eighth, which is 0.25 + 0.125 = 0.375.

Each bit position to the right of the radix point carries a weight of 2 raised to a negative power. The first fraction bit is worth 1/2, the second 1/4, the third 1/8, and so on. Every fraction you can write in a fixed number of bits is a finite sum of these weights.

That constraint is the whole story. Any sum of powers of two can be rewritten as a fraction whose denominator is a power of two. So the representable exact fractions are those of the form k/2^n, where k is an integer and n is the number of fraction bits. With 3 fraction bits, you get eighths. With 8 fraction bits, you get 256ths.

The reverse is the problem. A fraction like 1/3 has no finite binary expansion, because no finite sum of powers of two equals one third. If a denominator has any prime factor other than 2, the fraction repeats forever in binary. Fractions with denominators of 3, 5, 7, 10, and 100 all fail this test.

A plain-language version: binary can slice a whole into halves, quarters, eighths, and so on, but it cannot slice a whole into clean thirds or tenths.

How many fractions, and how close can you get

The count of exact fractions depends on the number of fraction bits, and the spacing between them shrinks as you add bits. The table below compares common storage formats and what they can represent.

Two details in that table matter. First, fixed-point formats keep a constant step size across their range. Floating-point formats keep a constant relative precision but a step size that grows with the magnitude of the number.

Second, the half, single, double, and quad rows follow the IEEE 754 standard for binary floating-point arithmetic. The standard defines how sign, exponent, and fraction fields combine, and it fixes the rounding rules that every conforming processor should follow.

Adding one fraction bit doubles the number of exact fractions and halves the step size. Going from 23 bits to 52 bits does not make 0.1 exact. It only makes the nearest representable value closer. The gap shrinks by roughly a factor of 2^29, but it never reaches zero.

That is the counterintuitive detail worth holding onto. More precision does not fix the representability problem; it only hides it. A binary64 number and a binary128 number both fail to equal 0.1, even though the second sits far closer.

Why 0.1 cannot be built from powers of two

Consider what it would take for a finite binary expansion to equal 1/10. Suppose the expansion had n fraction bits and equaled 1/10. Then multiplying both sides by 10 times 2^n would give an integer equal to a power of two, which forces a contradiction unless 10 divides a power of two. It does not, because 10 includes the prime factor 5.

The same argument rules out every fraction whose denominator, in lowest terms, contains a prime other than 2. That includes 1/3, 1/5, 1/6, 1/7, 1/9, 1/10, and 1/100. It excludes most everyday decimal values, including prices, percentages, and measurement readings.

What binary can do is approximate any of these to within half a step. The stored value for 0.1 in binary64 is slightly above 0.1, while the stored value for 0.2 is slightly above 0.2 as well. When you add them, the small errors accumulate, and the result prints as 0.30000000000000004 rather than 0.3.

That printout is not a bug in the processor. It is the honest decimal rendering of a binary sum. The sum is exactly representable in binary64; the surprise comes from expecting a decimal result from a binary machine.

Edge cases and failure modes

Several failure modes show up repeatedly when binary fractions meet real data.

Comparing two floating-point values with == after arithmetic. Two computations that should produce the same result can differ by one unit in the last place, and the equality test fails. Accumulating many small additions in a loop. Rounding error compounds with each step, so a million additions of 0.1 can drift noticeably from 100,000. Converting between binary and decimal text without enough digits. Printing fewer digits than the format supports, or parsing decimal input at low precision, can change the value stored. Using floating point for money. Amounts like USD 0.10, USD 0.20, and USD 30.00 have denominators that include 5, so exact decimal arithmetic is safer than binary. Assuming an integer type avoids the issue. The same limitation appears whenever you scale by a factor that is not a power of two, such as computing cents as hundredths of a unit at low precision. Relying on subtraction to test for zero. Cancellation of nearly equal values can produce a tiny nonzero result where you expected exact zero.

Each of these failures follows from the same root cause. The machine stores an approximation, and the program treats it as exact.

Misconceptions worth clearing

A common misconception is that floating point equals real-number arithmetic with a small error term. In practice, floating-point operations are exactly specified by the IEEE 754 standard, and the error depends on the operands and the order of operations. The same formula can give different results in a different order.

Another misconception is that doubles can represent every value a single can, so upgrading fixes the problem. A double can hold a wider range and more precision, but it still cannot hold 0.1 exactly. Upgrading from single to double moves the nearest representable value closer, and it changes which comparisons pass, but it does not change the set of exact fractions in any fundamental way.

A third misconception is that decimal fractions are somehow more natural. Decimal has the same problem in reverse. One third, one sixth, and one seventh all repeat in decimal, and no finite number of decimal digits equals them exactly. Decimal machines can store 0.1 exactly and fail on 1/3. Binary machines store 1/2 and 1/4 exactly and fail on 0.1.

A fourth misconception concerns the size of the error. People often assume the error is large enough to matter in ordinary calculations. Usually it is far below any practical threshold, and the problem appears only at the edges, where comparisons, accumulations, or exact accounting are required.

Professional caveat: exact-looking decimals can hide inexact binary

The professional caveat is that a decimal display can make an inexact binary value look exact. A program that prints two digits after the decimal point will show 0.10 for a stored value that is not exactly 0.10. The stored value may be slightly above or slightly below the true decimal.

This matters most when the stored values are compared, summed, or passed to another system that assumes exactness. A price stored in binary and rounded at display will look correct on screen and drift in a ledger.

The standard response is to choose a representation that matches the data's base. Decimal floating-point and integer arithmetic in the smallest exact unit both exist for this reason. The choice is not about avoiding approximation entirely. It is about aligning the approximation with the values the system must handle exactly.

Practical actions for exact fractions and safe conversions

The steps below are concrete thresholds and habits you can apply without special tools.

For money in US dollars, store the smallest unit as an integer, such as cents, and convert to dollars only for display. This keeps USD 0.10, USD 0.20, and USD 30 exactly representable. When comparing floating-point results, use a tolerance tied to the magnitude of the values. A common starting point for binary64 is a relative tolerance near 1e-12, adjusted to the problem. Print or serialize at least 17 significant digits for a binary64 value if you need the value to round-trip exactly. Do not use == on floating-point values that came from arithmetic. Compare the absolute difference against the tolerance instead. When summing many small values, sort by magnitude and add the smallest first, or use a compensated summation routine, to reduce drift. Record the unit and the base in your data schema. A field labeled "amount" without a base invites the kind of mismatch that binary fractions punish.

Limits of what bits can represent

The fixed-fraction-bit model, the floating-point model, and the decimal model all share a limit. Any format with finitely many bits can represent only a finite set of fractions exactly. The set is dense in the sense that you can always add more bits, but density is not the same as covering every real number.

Binary formats are also not the only choice. A decimal format can store 0.1 exactly and fails on 1/3. A rational representation can store both exactly, but it must track a numerator and denominator, and it can overflow. Each format trades one set of exact values for another.

The answer to the keyword question is therefore no on two grounds. You cannot create every possible fraction with any finite number of bits. And even a binary format with an unlimited number of fraction bits would only catch fractions whose denominators divide a power of two, so the reachable set excludes every fraction with a prime factor other than 2 in its lowest-terms denominator.

For a machine, the practical goal is not universal exactness. The goal is to know which fractions your format holds exactly, which it approximates, and how much error those approximations can accumulate before they cross a threshold that matters. That knowledge turns a subtle rounding problem into a design choice.