Floating point problems (accuracy).

[Joe Hughes]

The problem you are encountering stems from the fact that by default gcc 
on x86 platform uses 80-bit extended precision registers, compared with 
64-bit on the other architecture.
There are all kinds of possible work around solutions depending on what 
your application does. I would not recommend putting the
processor into the standard IEEE double precision mode by setting the
floating point control word as pthread_cond_timedwait calls appear to 
change the processor mode back to extended precision and you'll never 
know it.  Unless patching your linux kernel and keeping your own version 
of linux around appeals to you I would suggest you can minimize the 
impact of this by storing all computations in temporary variables to 
force the doubles out of the registers. You might find an issue with 
your temporary variables being optimized out by the compiler so 
declaring them as volatile double will address this issue.






Phil Prentice wrote on 1/18/2005, 1:33 PM:

 > Hi
 >   We are having a few problems regarding floating point inaccuracies
 > under
 >   Linux.  Please see the code below.
 >
 > /*
 > NOTE:-  This code is an example which demonstrates the sort of problems
 >         we are getting.
 > */
 > main()
 > {
 >   int i;
 >   double x;
 >
 >   x = -5.765;
 >   i = x * 100000;
 >   printf("I = %d\n",i);
 >
 > }
 >
 > /*
 >
 > We are porting code from a Sun Workstation to a Linux PC.  We have
 > noticed
 > inaccuracies of double values on the Linux PC.  If we simply compile the
 > above program e.g "gcc t.c" when we run it we get -576499 when we were
 > really
 > expecting -576500.  We discovered that if we specify some flags:-
 >
 > gcc -march=pentium4 -mfpmath=sse t.c
 >
 > then suddenly the floating point values become more accurate (i.e. we
 > get the
 > value -576500) and other related problems go away (our results agree
 > with the
 > same tests running on the Sun).
 >
 > These flags only seem to work on a pentium4 or an AMD-64, i.e the newer
 > processor chips.  We would have liked the solution to be more generic.
 >
 > Does any one know a better way of fixing this?
 >
 > What was the solution for the older processor chips?
 >
 > Is there a generic solution?
 >
 > Thanks for all your help
 >
 >   Phil Prentice.
 >