102 3. Fundamentals of Software Engineering for Games
least signifi cant digit of the mantissa. Those trailing zeros don’t correspond
to any actual bits in our 32-bit fl oating-point value—they just appear out of
thin air because of the exponent. If we were to subtract a small number (where
“small” means any number composed of fewer than 26 hexadecimal digits)
from FLT_MAX, the result would still be FLT_MAX, because those 26 least sig-
nifi cant hexadecimal digits don’t really exist!
The opposite eff ect occurs for fl oating-point values whose magnitudes
are much less than one. In this case, the exponent is large but negative, and
the signifi cant digits are shift ed in the opposite direction. We trade the ability
to represent large magnitudes for high precision. In summary, we always have
the same number of signifi cant digits (or really signifi cant bits) in our fl oating-
point numbers, and the exponent can be used to shift those signifi cant bits into
higher or lower ranges of magnitude.
Another subtlety to notice is that there is a fi nite gap between zero and the
smallest nonzero value we can represent with any fl oating-point notation. The
smallest nonzero magnitude we can represent is FLT_MIN = 2–126 ≈ 1.175× 10 –38,
which has a binary representation of 0x00800000 (i.e., the exponent is 0x01,
or –126 aft er subtracting the bias, and the mantissa is all zeros, except for the
implicit leading one). There is no way to represent a nonzero magnitude that
is smaller than 1.175× 10 –38, because the next smallest valid value is zero. Put
another way, the real number line is quantized when using a fl oating-point
representation.
For a particular fl oating-point representation, the machine epsilon is de-
fi ned to be the smallest fl oating-point value ε that satisfi es the equation, 1 +
ε ≠ 1. For an IEEE-754 fl oating-point number, with its 23 bits of precision, the
value of ε is 2–23, which is approximately 1.192× 10 –7. The most signifi cant digit
of ε falls just inside the range of signifi cant digits in the value 1.0, so adding
any value smaller than ε to 1.0 has no eff ect. In other words, any new bits con-
tributed adding a value smaller than ε will get “chopped off ” when we try to
fi t the sum into a mantissa with only 23 bits.
The concepts of limited precision and the machine epsilon have real im-
pacts on game soft ware. For example, let’s say we use a fl oating-point vari-
able to track absolute game time in seconds. How long can we run our game
before the magnitude of our clock variable gets so large that adding 1/30th of
a second to it no longer changes its value? The answer is roughly 12.9 days.
That’s longer than most games will be left running, so we can probably get
away with using a 32-bit fl oating-point clock measured in seconds in a game.
But clearly it’s important to understand the limitations of the fl oating-point
format, so that we can predict potential problems and take steps to avoid them
when necessary.