Code_ The Hidden Language of Computer Hardware and Software - Charles Petzold [144]
If e equals 0 and f doesn't equal 0, the number is valid, but it's not normalized. The number equals
(–1)s x 0.f x 2-127
Notice that the significand has a 0 to the left of the binary point.
If e equals 255 and f equals 0, the number is positive or negative infinity, depending on the sign s.
If e equals 255 and f doesn't equal 0, the value is considered to be not a number, which is abbreviated NaN. A NaN could indicate an unknown number or the result of an invalid operation.
The smallest normalized positive or negative binary number that can be represented in single-precision floating-point format is
1.00000000000000000000000TWO x 2-126
That's 23 binary zeros following the binary point. The largest normalized positive or negative number is that can be represented in single-precision floating-point format is this:
1.11111111111111111111111TWO x 2127
In decimal, these two numbers are approximately 1.175494351 x 10-38 and 3.402823466 x 1038. That's the effective range of single-precision floating-point notation.
You might recall that 10 binary digits are approximately the same as 3 decimal digits. By that I mean that 10 bits set to 1, which is 3FFh in hexadecimal and 1023 in decimal, is approximately equal to 3 decimal digits set to 9, or 999. Or
210 ≈ 103
This relationship implies that the 24-bit binary number stored in single-precision floating-point format is roughly the equivalent of 7 decimal digits. For this reason, it's said that the single-precision floating-point format offers a precision of 24 bits, or about 7 decimal digits. What does this mean?
When we were looking at fixed-point numbers, it was obvious how accurate the numbers were. For amounts of money, for example, a fixed-point number with two decimal places is obviously accurate to the nearest penny. But with floating-point numbers, we can't say something like that. Depending on the value of the exponent, sometimes a floating-point number can be accurate to a tiny fraction of a penny, and sometimes it's not even accurate to the nearest dollar.
It's more appropriate to say that a single-precision floating-point number is accurate to 1 part in 224, or 1 part in 16,777,216, or about 6 parts in a million. But what does this really mean?
For one thing, it means that if you try to represent both 16,777,216 and 16,777,217 as single-precision floating-point numbers, they'll end up being identical! Moreover, any number between those two (such as 16,777,216.5) is also considered to be identical. All three of these decimal numbers are stored as the 32-bit single-precision floating-point value
4B800000h
which, divided into the sign, exponent, and significand bits, looks like this:
0 10010111 00000000000000000000000
which is the number
1.00000000000000000000000TWO x 224 .
The next-highest significand is the binary floating-point number that represents 16,777,218 or
1.00000000000000000000001TWO x 224
It might or might not be a problem that two different decimal numbers end up being stored as identical floating-point values.
But if you were writing a program for a bank, and you were using single-precision floating-point arithmetic to store dollars and cents, you probably would be deeply disturbed to discover that $262,144.00 is the same as $262,144.01. Both these numbers are
1.00000000000000000000000TWO x 218 .
That's one reason why fixed-point is preferred when dealing with dollars and cents. When you work with floating-point numbers, you could also discover other little quirks that can drive you mad. Your program will do a calculation that should yield the result 3.50 and instead you get 3.499999999999. This type of thing tends to happen in floating-point calculations, and there isn't a whole lot you can do about