Oh, and how do you imagine 1/3 being stored in your model? There's no pair of integers m and e where m * 10^e gives 1/3. Your model doesn't work for periodic numbers.
You could approximate it. You could use m = 3333333333 and e = -10, but it's not quite exact.
And guess what. That's exactly the problem faced here.
The number is stored as two integers. But it's not a power of 10; it's a power of 2.
So, in this case, you need a pair of integers m and e where m * 2^e = 895/100. There is no such pair of integers because 895/100 is periodic in binary.
So the computer used m = 0x11E66666666666 and e = -49, but it's not quite exact.
$ perl -Mv5.14 -e'say 8.95 == 0x11E66666666666 * 2**(-49) ? 1 : 0' 1 $ perl -Mv5.14 -e'say sprintf "%.751g", 0x11E66666666666 * 2**(-49)' 8.949999999999999289457264239899814128875732421875 $ perl -Mv5.14 -e'say sprintf "%.751g", 8.95' 8.949999999999999289457264239899814128875732421875
If you want to be picky, an IEEE double is actually stored as follows to get a couple of extra bits:
( -1 )^s * ( 1 + ( m * 2^( -52 ) ) * 2^( e - 1023 ) )
In reply to Re^3: Behaviour of int() unexpected
by ikegami
in thread Behaviour of int() unexpected
by ceade1000
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |