4:27 > "Every binary floating point number has an exact decimal equivalent, but not every decimal number has an exact binary equivalent. And the reason for that, you know, is that powers of two and powers of ten are only compatible in one direction, not in the other."
This is because 1/2 is representable as a fraction with 10 in the denominator: 5/10. All fractional digits after the binary point are just powers of 1/2, thus powers of 5/10. Division by ten in decimal doesn't produce any repeating digits.
Here is where the above is slightly misleading, though. The number of decimal digits to capture that exact decimal value of a binary floating point with an n-bit mantissa may be far in excess of the actual decimal precision that is contained in an n-bit mantissa.
In the case of the IEEE 64 bit double we need 17 decimal digits to capture a printed decimal representation which will reproduce the original double. That representation isn't the exact decimal number; much more than 17 digits may be required to get the exact decimal value. The exact decimal value is, I think, rarely of interest. In an ordinary application of floating point numbers, we don't print double values to, say, 30 digits of precision; anything after 17 is "junk".
In the other direction, only 15 decimal digits of precision are guaranteed to be preserved by the representation, so in a 17 digit print, digits 16 and 17 are also "dodgy"; they serve only to record the object exactly.
You're right, but I don't think it qualifies as misleading since the whole algorithm is exactly about finding the minimal expansion for a specific number.
This is because 1/2 is representable as a fraction with 10 in the denominator: 5/10. All fractional digits after the binary point are just powers of 1/2, thus powers of 5/10. Division by ten in decimal doesn't produce any repeating digits.
Here is where the above is slightly misleading, though. The number of decimal digits to capture that exact decimal value of a binary floating point with an n-bit mantissa may be far in excess of the actual decimal precision that is contained in an n-bit mantissa.
In the case of the IEEE 64 bit double we need 17 decimal digits to capture a printed decimal representation which will reproduce the original double. That representation isn't the exact decimal number; much more than 17 digits may be required to get the exact decimal value. The exact decimal value is, I think, rarely of interest. In an ordinary application of floating point numbers, we don't print double values to, say, 30 digits of precision; anything after 17 is "junk".
In the other direction, only 15 decimal digits of precision are guaranteed to be preserved by the representation, so in a 17 digit print, digits 16 and 17 are also "dodgy"; they serve only to record the object exactly.