Re: floating point comparison

[Samuel Mize <smize@link.com>]

[reformatted for line length]
Matthew Heaney wrote:
> 
> In article <dewar.870304869@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) wrote:
> 
> >As for when it makes sense to compare floating-point values
> >for equality, that is a matter for the programmer to understand.
> >Floating-point arithmetic on modern IEEE machines is not some kind
> > of approximate hocus-pocus, it is a well defined arithmetic systenm,
> >with well defined, well behaved results, in which equality has a
> > perfectly reasonable meaning.
> 
> OK, so if  do this
> 
> declare
>    m1, m2 : slope;
> begin
>    if m1 = m2 then
> 
> and I'm using IEEE floating point types (I'm on a SUN box), can I assume
> that the lines are parallel?

IEEE float calculation is a well-defined arithmetic system, but it
does not always match exact real-number arithmetic.  You need to
read up in one or more of the references other people provided, to
determine how the differences impact your computations.

The short answer is that there is no short answer.

The longer short answer is that usually, the inaccuracy of the data
swamps the imprecision of discrete floating-point arithmetic.  If
you're measuring lengths under 10 yards to the nearest foot, it really
doesn't matter if you compute the rectangular area with 32 or 64 bits.
In this case, you might consider 10.01 and 9.09 equal.  If you're
measuring to the nearest inch, you might not.  In neither case are
you approaching the precision of the machine.

There are cases where the machine precision plays a part.  For instance,
solution by successive approximation may thrash indefinitely if the
value you are hunting is further than your "close enough" criterion
from two "adjacent" approximations.

You might also find that the computations you are doing introduce a
significant level of imprecision due to representation limits, although
usually anything that amplifies imprecision also amplifies the
inaccuracy of your data.

And there are special boundary cases, e.g. trig functions zooming off
to infinity.

There really is no substitute for some knowledge of numerical analysis,
even if self-taught.  You have to at least know enough to tell when you
are safe, and when you need to be careful.  There isn't a set of
cookbook directions that will guide you.

What makes Ada intimidating in this respect is that the standard tries
to make these issues visible and controllable, instead of giving you
whatever's on the machine and ignoring the problem.  (A language like
that wouldn't get a better grade than C.)*

Best,
Sam Mize

* Yes, it was gratuitous.  :-)