It's called floats. Floats are not exact. Try the following C-program:
#include <stdio.h> int main() { printf("%f %f\n", (float)35.8, 35.8); return 0; }
If you want exact calculations you don't want floats. Of course, if you compile with with doubles rather than floats, you get better approximations (but still not exact).
/ David Hedbor
Previous text:
2003-02-25 09:29: Subject: Do we have a floatingpoint bug?
Yesterday I had to write a program which rescaled and rounded off some coordinates for use in a lab. I found something that worries me quite a bit:
({ /* 22 elements */ ({ /* 2 elements */ 639.000000, 37.000000 }), ({ /* 2 elements */ 426.000000, 99.000000 }), ({ /* 2 elements */ 538.000000, 103.000000 }), ({ /* 2 elements */ 698.000000, 105.000000 }), ({ /* 2 elements */ 813.000000, 104.000000 }), ({ /* 2 elements */ 480.000000, 199.000000 }), ({ /* 2 elements */ 633.000000, 195.000000 }), ({ /* 2 elements */ 780.000000, 196.000000 }), ({ /* 2 elements */ 480.000000, 304.000000 }), ({ /* 2 elements */ 636.000000, 308.000000 }), ({ /* 2 elements */ 785.000000, 309.000000 }), ({ /* 2 elements */ 425.000000, 388.000000 }), ({ /* 2 elements */ 536.000000, 397.000000 }), ({ /* 2 elements */ 700.000000, 401.000000 }), ({ /* 2 elements */ 814.000000, 399.000000 }), ({ /* 2 elements */ 625.000000, 457.000000 }), ({ /* 2 elements */ 480.000000, 252.000000 }), ({ /* 2 elements */ 633.000000, 256.000000 }), ({ /* 2 elements */ 780.000000, 259.000000 }), ({ /* 2 elements */ 480.000000, 349.000000 }), ({ /* 2 elements */ 636.000000, 347.000000 }), ({ /* 2 elements */ 785.000000, 358.000000 }) }) ({ /* 22 elements */ ({ /* 2 elements */ 63.900002, 3.700000 }), ({ /* 2 elements */ 42.599998, 9.900000 }), ({ /* 2 elements */ 53.799999, 10.300000 }), ({ /* 2 elements */ 69.800003, 10.500000 }), ({ /* 2 elements */ 81.300003, 10.400000 }), ({ /* 2 elements */ 48.000000, 19.900000 }), ({ /* 2 elements */ 63.299999, 19.500000 }), ({ /* 2 elements */ 78.000000, 19.600000 }), ({ /* 2 elements */ 48.000000, 30.400000 }), ({ /* 2 elements */ 63.599998, 30.799999 }), ({ /* 2 elements */ 78.500000, 30.900000 }), ({ /* 2 elements */ 42.500000, 38.799999 }), ({ /* 2 elements */ 53.599998, 39.700001 }), ({ /* 2 elements */ 70.000000, 40.099998 }), ({ /* 2 elements */ 81.400002, 39.900002 }), ({ /* 2 elements */ 62.500000, 45.700001 }), ({ /* 2 elements */ 48.000000, 25.200001 }), ({ /* 2 elements */ 63.299999, 25.600000 }), ({ /* 2 elements */ 78.000000, 25.900000 }), ({ /* 2 elements */ 48.000000, 34.900002 }), ({ /* 2 elements */ 63.599998, 34.700001 }), ({ /* 2 elements */ 78.500000, 35.799999 }) }) [agehall@omicron ~] pike --version Pike v7.5 release 1 Copyright © 1994-2002 Linköping University Pike comes with ABSOLUTELY NO WARRANTY; This is free software and you are welcome to redistribute it under certain conditions; Read the files COPYING and COPYRIGHT in the Pike distribution for more details.
The first array(array(float)) are the values as read from the file. The second array(array(float)) contains the values divided by 10. Note how some numbers become +-0.000001. This is very strange and not very good at all... I am able to reproduce the bug by doing
358.0/10;
(1) Result: 35.799999
on both my PPro/Linux running Pike 7.5 and a Sun/Solaris running Pike 7.3. Is this a known bug and is there a workaround?
/ Marcus Agehall (Trådlös)