Pike doesn't do anything magical with floats; all¹ work on floats is up to the C compiler and libc.
Pike's default float type, "float", have superbad precision (7½ digits, 1.0+1e-8==1.0). So your figures are correct as far as the precision will take you.
If you need more precision, maybe Math.Matrix can help you (it uses "double" on all systems), or you can compile Pike with --with-double-precision or --with-long-double-precision to get better default precision.
(¹ Pike has some builtin knowledge of IEEE float formats used in sprintf/sscanf %F, binary input and output. Not applicable here.)
/ Mirar
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)