Why decimals get awkward in binary
Computers store ordinary floating-point numbers using base 2: each place represents a power of two, much as decimal places represent powers of ten. Fractions such as one-half fit neatly in binary, but one-tenth does not. Its binary expansion continues indefinitely, just as one-third is 0.333… in decimal.
A computer has room for only a finite number of bits, so it stores the nearest representable value instead. The stored versions of 0.1 and 0.2 are each slightly off. When the processor adds them, it adds those approximations and rounds the result to another representable value. That value is a little greater than exact 0.3, and many languages display it as `0.30000000000000004`.
A tiny error can matter in the wrong place
This is not usually a sign that the addition operation is broken. Floating-point arithmetic is designed to handle a vast range of values efficiently, accepting small rounding differences along the way. Those differences can become visible when results are printed, compared for exact equality, or accumulated through many calculations.
For money, where a fraction of a cent may have real consequences, programs often avoid this representation for basic amounts. They can store dollars as whole cents—$1.23 becomes 123—or use decimal arithmetic designed to represent decimal fractions directly. For scientific and graphics calculations, floating point is often the practical choice; code can account for its limits by using an appropriate tolerance when comparing results.
The key distinction is between the number a person writes and the finite binary approximation a computer can store. A displayed result can look like a simple decimal sum even when the machine has been adding nearby values all along.
