Author: Robert Hyatt
Date: 20:11:47 09/09/02
Go up one level in this thread
On September 09, 2002 at 14:05:30, Vincent Diepeveen wrote:
>On September 09, 2002 at 13:32:42, Ed Panek wrote:
>
>use a different compiler. gcc 3.2 or something instead of 5 years old
>RH6.
>
>It's like me blaming m$ for bugs in windows NT 4.0 which is from 1995.
Same here. This is _not_ a compiler bug. It is a simply an artifact of
using floating point math. Well-known to those of us that have done this
very much.
>
>Basically the problem of intel c++ is way simpler, let's just
>guess something:
>
>int myfunctionCORRELATIONtoINT(float a,float b,float c) {
> bla bla with a,b,c; ...
> return((int)(a*b+c));
>}
>
>Other compilers than intel c++ do not do it wrong.
>
>>Red Hat Linux release 6.0 (Hedwig)
>>Kernel 2.2.5-15 on an i686
>>
>>Here is just one example of unpredictable floating point behavior. I ran the
>>following program on RH and on my Mac G4:
>>
>>#include <stdlib.h>
>>#include <stdio.h>
>>#include <math.h>
>>
>>void main( void )
>>{
>> double a,b,c,d;
>> double a_int, a_fract;
>> double b_int, b_fract;
>> double c_int, c_fract;
>>
>> int i,j;
>>
>> for( i = 8; i < 13; ++i )
>> {
>> a = (double)i;
>> b = a / 1000.0;
>>
>> d = 1000.0;
>> c = b * d;
>> j = (int)(b * d);
>>
>>
>> a_fract = modf(a, &a_int);
>> b_fract = modf(b, &b_int);
>> c_fract = modf(c, &c_int);
>>
>> printf("i = %d, a = %35.30f, b = %35.30f, c = %35.30f, j =
>>%d\n",i,a,b,c,j);
>> printf("a = %35.30f + %35.30f\n", a_int, a_fract);
>> printf("b = %35.30f + %35.30f\n", b_int, b_fract);
>> printf("c = %35.30f + %35.30f\n", c_int, c_fract);
>>
>> }
>>
>> return;
>>
>>}
>>
>>The output on RH is as follows:
>>
>>
>>
>>testit
>>i = 8, a = 8.000000000000000000000000000000, b =
>>0.008000000000000000166533453694, c = 8.000000000000000000000000000000, j =
>>8
>>a = 8.000000000000000000000000000000 + 0.000000000000000000000000000000
>>b = 0.000000000000000000000000000000 + 0.008000000000000000166533453694
>>c = 8.000000000000000000000000000000 + 0.000000000000000000000000000000
>>
>>i = 9, a = 9.000000000000000000000000000000, b =
>>0.008999999999999999319988397417, c = 9.000000000000000000000000000000, j =
>>8
>>a = 9.000000000000000000000000000000 + 0.000000000000000000000000000000
>>b = 0.000000000000000000000000000000 + 0.008999999999999999319988397417
>>c = 9.000000000000000000000000000000 + 0.000000000000000000000000000000
>>
>>i = 10, a = 10.000000000000000000000000000000, b =
>>0.010000000000000000208166817117, c = 10.000000000000000000000000000000, j =
>>10
>>a = 10.000000000000000000000000000000 + 0.000000000000000000000000000000
>>b = 0.000000000000000000000000000000 + 0.010000000000000000208166817117
>>c = 10.000000000000000000000000000000 + 0.000000000000000000000000000000
>>
>>i = 11, a = 11.000000000000000000000000000000, b =
>>0.010999999999999999361621760841, c = 11.000000000000000000000000000000, j =
>>10
>>a = 11.000000000000000000000000000000 + 0.000000000000000000000000000000
>>b = 0.000000000000000000000000000000 + 0.010999999999999999361621760841
>>c = 11.000000000000000000000000000000 + 0.000000000000000000000000000000
>>
>>In the above case, the cast to int truncates and leaves the integer too small by
>>1 in some cases. But, suprisingly, the modf() routine returns data that is
>>corrected for the error.
>> Where is the correction happenning? In modf()? By the CPU when the result is
>>stored back?
>>
>>On my mac, the CPU and/or libraries do some magic to correct this so that the
>>underlying data IS whole number data before the cast, or else the cast is very
>>smart. In this case, the cast and the printf() agree. I will note that it is
>>possible the compiler is very smart and factored the divide and multiply by 1000
>>out of the equation... But I doubt it.
>>
>>Power PC G4 output:
>>
>>
>>testit
>>i = 8, a = 8.000000000000000000000000000000, b =
>>0.008000000000000000166533453694, c = 8.000000000000000000000000000000, j =
>>8
>>a = 8.000000000000000000000000000000 + 0.000000000000000000000000000000
>>b = 0.000000000000000000000000000000 + 0.008000000000000000166533453694
>>c = 8.000000000000000000000000000000 + 0.000000000000000000000000000000
>>
>>i = 9, a = 9.000000000000000000000000000000, b =
>>0.008999999999999999319988397417, c = 9.000000000000000000000000000000, j =
>>9
>>a = 9.000000000000000000000000000000 + 0.000000000000000000000000000000
>>b = 0.000000000000000000000000000000 + 0.008999999999999999319988397417
>>c = 9.000000000000000000000000000000 + 0.000000000000000000000000000000
>>
>>i = 10, a = 10.000000000000000000000000000000, b =
>>0.010000000000000000208166817117, c = 10.000000000000000000000000000000, j =
>>10
>>a = 10.000000000000000000000000000000 + 0.000000000000000000000000000000
>>b = 0.000000000000000000000000000000 + 0.010000000000000000208166817117
>>c = 10.000000000000000000000000000000 + 0.000000000000000000000000000000
>>
>>i = 11, a = 11.000000000000000000000000000000, b =
>>0.010999999999999999361621760841, c = 11.000000000000000000000000000000, j =
>>11
>>a = 11.000000000000000000000000000000 + 0.000000000000000000000000000000
>>b = 0.000000000000000000000000000000 + 0.010999999999999999361621760841
>>c = 11.000000000000000000000000000000 + 0.000000000000000000000000000000
>>
>>i = 12, a = 12.000000000000000000000000000000, b =
>>0.012000000000000000249800180541, c = 12.000000000000000000000000000000, j =
>>12
>>a = 12.000000000000000000000000000000 + 0.000000000000000000000000000000
>>b = 0.000000000000000000000000000000 + 0.012000000000000000249800180541
>>c = 12.000000000000000000000000000000 + 0.000000000000000000000000000000
>>
>>
>>All very interesting to me... But the bottom line is that floating point is
>>spooky.
>>
>>
>>Comments?
>>
>>
>>Ed
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.