Re: floating point comparison

[dewar@merv.cs.nyu.edu (Robert Dewar)]

James Carr says

<< The difference is inevitable.  It does exist.  It has important
 consequences when interpreting the result of a calculation that
 is being used as a substitute for working with real numbers, a
 major reason computers exist.  If you do not like the name,
 propose another -- but do not pretend that it does not happen.
>>


I think you should assume that I do understand how floating-point works,
and I have written hundreds of thousands of lines of numerical Fortran
code, carefully analyzed, much of which is still in use today, even
though that was some thirty years ago!

The point, which perhaps you just don't see, because I assume you also
understand floating-point well, is that I think the term "error" for
the discrepancies that occur when an arbitrary decimal number is converted
to binary floating-point are not errors. An error is something wrong. There
is nothing wrong here, you habve made the decision to represent a decimal
value in binary form, and used a method that gives a very well defined
result. If this is indeed an "error", then please don't use methods that
are in error, represent the number some other way. If on the other hand,
your analysis shows that the requirements of the calculation are met by
the use of this conversion, then there is no error here!

Similarly when we write a := b + c, the result in a is of course not the
mathematical result of adding the two real numbers represented by b and c,
but there is no "error". An error again is something wrong. If an addition
like that is an error, i.e. causes your program to malfunction, then don't
do the addition.

If on the other hand, your analysis shows that it is appropriate to perform
the computation a = b + c, where a is defined as the result required by
IEEE854, then there is no error.

Yes, it is useful to have a term to describe the difference between the
IEEE result and the true real arithmetic result, but it is just a
difference, and perhaps it would be better if this value had been called
something like "rounding difference", i.e. something more neutral than
error.

The trouble with the term error, is that it feeds the impression, seen
more than once in this thread, that floating-point is somehow unreliable
and full of errors etc.

Go back to the original subject line of this thread for a moment.

Is it wrong to say

   if a = b then

where we know exactly how a and b are represnted in terms of IEEE854, and
we know the IEEE854 equality test that will be performed/

The answer is that it might be wrong or it might be right. it has a well
defined meaning, and if that meaning is such that your program works, it
is right, if that meaning is such that your program fails, then it is wrong.

But --- we could make the same statement about any possible programming
language statement we might write down.

There is nothing inherently wrong, bad, erroneous, or anything else like
that about floating-point.

Now one caveat is that we often do NOT know how statements we write will
map into IEEE854 operations unless we are operating in a well defined
environment like SANE. As I have noted before, this is a definite gap
in programming language design, and is specifically the topic that my
thesis student Sam Figueroa is working on.