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

[Paul E Johnson]

Ted Belding (a long time Swarmer at U Mich) posted a message about the 
comparison of doubles and he has some software to try to help, but he 
did caution it slows things down.

http://fcmp.sourceforge.net/

I was in the gcc list a few weeks back and there was discussion of 
floating point accuracy and I think they are aware of some of these issues.

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

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?


Gary Polhill wrote:
> I don't think it's just printf, I'm afraid. Try the attached program. This takes as 
> argument a number of times to add a constant to 0.0 and then subtract it again. I've 
> done it using the same permutations of long doubles and L constant modifiers as you, 
> but from my C book (Schildt, 1987), which may not be the ultimate authority, long 
> double constants take the L modifier, doubles have no modifier, and floats get an F. 
> At the end, the program tells you whether the result is less than, greater than, or 
> equal to 0.0, using comparison operators, not printf. The only consistently correct 
> result I get (on a Solaris machine) is with long double *not* using the L constant 
> modifier! More disturbingly still, adding 0.4 to a double 0.0 19 times and then 
> subtracting 0.4 19 times gives a result that is > 0.0, but doing the same 20 times 
> gives a result that is < 0.0.
>
> I think this is a particular issue for agent-based models. I don't think we can 
> be the only ABM out there adding or subtracting some score to an agent each 
> cycle according to its performance, and then doing something to that agent if 
> its score drops below 0.0. The whole point of agent-based modelling is that the 
> individual can make a difference, so it matters *when* in the simulation the 
> agent has something done to it because its score is negative.
>
> Gary
>
>
> > > > <address@hidden> 15/10/02 19:27:06 >>>
>
> I think what you're dealing with is the conversion operation of the
> print function.  Since %f assumes a double and %g and %e assume
> long doubles, you're going to run into these problems because it
> scarfs whatever trash happens to surround the thing you're printing.
>
> Check out the attached program and its results.  Basically, the
> problem is not floating point arithmetic... it's the proper use
> of constants.
--
Paul E. Johnson                       email: address@hidden
Dept. of Political Science            http://lark.cc.ku.edu/~pauljohn
1541 Lilac Lane, Rm 504
University of Kansas                  Office: (785) 864-9086
Lawrence, Kansas 66044-3177           FAX: (785) 864-5700



                 ==================================
  Swarm-Modelling is for discussion of Simulation and Modelling techniques
  esp. using Swarm.  For list administration needs (esp. [un]subscribing),
  please send a message to <address@hidden> with "help" in the
  body of the message.
                 ==================================