doubts

[Andreas Jaeger]

>>>>> muench  writes:

 > Hi,
 > I don't know if your are responsible for the behaviour of functions 
 > included in tg_math.h, like floor. We use ecgs-1.1.2 and possible
 > you have fixed that, than excuse me.
<tgmath.h> comes on Linux with glibc 2.1.
 > This mail should be an response of some users from gcc.

 > What we program is:

 >   x = 5.05/0.01;
 >   y = floor(x);
 >   printf("x=%20.10e, floor(x)=%e \n", x, y); 
 >   x = 5.06/0.01;
 >   y = floor(x);
 >   printf("x=%25.16e, floor(x)=%e \n", x, y);

 > x=    5.0500000000e+02, floor(x)=5.050000e+02
 > x=    5.0599999999999994e+02, floor(x)=5.050000e+02
 > x=    5.0500000000e+02, floor(x)=5.050000e+02
 > x=    5.0599999999999994e+02, floor(x)=5.050000e+02   

 > Now floor compute right from mathematical point of view, 
 > The next value to 5.0599999999999994e+02 is 5.05. But
 > in our opinion it isn't in programmers responsibility to
 > control the storage values. The function must control
 > such numerical errors by itself, perhaps by using DBL_EPSILON
 > or something else. With that current behaviour it is 
 > unsecure to use the provided functions of math.h and it isn't
 > friendly to users.
How should it?  ISO C 99 defines:
       [#2]  The  floor functions compute the largest integer value
       not greater than x: |x|.

Therefore we're not allowed to round up to 506.  The compiler could be
clever and notice that 5.06/0.01 506 and store this value as exact
value - but 0.01 and 5.06 cannot be represented as exact floating
point numbers.
 > The only way to beware of such problems is programm much function
 > as possible by myself an spend no much trust too gcc functions.
 > That can not be the right way.
I fear there's no other way.

I advise to read "What every computer scientist should know about
floating point" from David Goldberg (cited from memory).

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.rhein-neckar.de