Floating Point Number Problem (Re: Swarm Futures re-cap

[Gary Polhill]

>>> Paul Johnson wrote:
>
>I ran the attached program with gcc-3.0.4 and see this.  Is it the same 
>as you see?  Why at the end do I see equality for the third one?
>
>$ gcc -o fp fp-selection.c
>
>$ ./fp 109
>START
>double 0.0 is now == 0.0
>double 0.0L is now == 0.0L
>long double 0.0 is now == 0.0
>long double 0.0L is now == 0.0L
>MIDDLE
>double 0.0 is now > 0.0
>double 0.0L is now > 0.0L
>long double 0.0 is now > 0.0
>long double 0.0L is now > 0.0L
>END
>double 0.0 is now < 0.0
>double 0.0L is now < 0.0L
>long double 0.0 is now == 0.0
>long double 0.0L is now > 0.0L

At the end I get (with gcc-3.0.2):

END
double 0.0 is now < 0.0
double 0.0L is now < 0.0L
long double 0.0 is now == 0.0
long double 0.0L is now < 0.0L

I have no idea why the third one should be equal and the rest not. I guess 
properly I should get a copy of gcc-3.0.4 so we can check if the difference 
between our answers on the fourth is a platform or compiler issue...

>
>I notice that I can get result we want if I make the comparison against 
>an epsilon difference, something like this:
>
>  if (fabs(n_d - n_dL) > 0.00001) printf ("n_d and n_dL are not the same");
>   else  printf ("n_d and n_dL are the same") ;
>
>Would this be a simple way to avoid the problem?
>

I guess it would be a simple way to avoid the problem if:

(a) You could guarantee that in your simulation, for all parameter settings, 
the difference between the variables being compared is always going to be 
greater than epsilon.

(b) You could also guarantee that floating point errors will never be greater 
than epsilon. My colleague, Luis Izquierdo, has found, using a program similar 
to the one I sent round in my previous message that prints out the numbers in 
each variable rather than comparing them, that the floating point errors 
increase as the number of iterations increase (see attached code). So, for 
example, adding 0.4 20 times and then subtracting 0.4 20 times to a number 
initially set to 0.0 ends up with a result that is roughly 7E-16 away from 0.0. 
But doing the same 2630000 times instead of 20 ends up with a result that is 
1E-10 away from 0.0. At some point, though, you are going to hit the maximum 
number you can sensibly add 0.4 to with a double, but I don't think it is at 
this point yet...

My guess is that such guarantees would not be easy to make at compile time, but 
then I suppose you could always pass epsilon in as a parameter (rounding errors 
notwithstanding!) rather than hard-coding it. However, you then end up with an 
utterly artefactual parameter to your simulation.

Whilst I agree with Andy Cleary's point that worrying about floating point 
arithmetic should be the preserve of only a privileged view, it's clear that 
there is a best practice issue here. Just as with such things as random number 
generation and scheduling, it is a best practice issue that most Swarm 
modellers will not want to trouble themselves with, which is what makes me 
wonder if Swarm should have a library dealing with floating point arithmetic 
properly somehow.

Gary

fp-value.c
Description: Text document