This is the mail archive of the
`gcc@gcc.gnu.org`
mailing list for the GCC project.

# Re: Fourth Draft "Unsafe fp optimizations" project description.

*To*: ejr at CS dot Berkeley dot EDU, kaih at khms dot westfalen dot de
*Subject*: Re: Fourth Draft "Unsafe fp optimizations" project description.
*From*: dewar at gnat dot com
*Date*: Wed, 15 Aug 2001 19:31:31 -0400 (EDT)
*Cc*: gcc at gcc dot gnu dot org

<<If there's one thing I've seen or heard in just about *every* discussion
of computer floating point, it is that you cannot rely on equality. Just
about every single one makes the point that with floating point, "A == B"
is *wrong*, you want "abs(A-B) < some_small_value".
>>
That's because a lot of discussions of computer floating-point are
misinformed. Of *course* you can rely on equality. It tells you if
two floating-point numbers are equal. For example, if you are hashing
floating-point numbers, then *OF COURSE* you want to do absolute
equality tests to see if you have found the entry you are looking for.
Another example would be a Newton-Raphson square root, which you know will
converge to absolte equality given the floating-point model you are using.
What is wrong is the completely misinformed claim that it is always
inappropriate to do equality checks on floating-point.
Once again, think about what such a claim means, it means that everyone
involved in design of programming languages from Fortran on is wrong, and
you are right. In fact what is going on is that a LOT of people use and
write about floating-point arithmetic without knowing enough to do so,
but when it comes to programming language design, you expect informed
input (for instance, the floating-point model in Ada was designed and
discussed by skilled numerical analysts from Argonne and elsewhere around
the world).
The replacement "abs (A - B) < some small value
may be appropriate in some cases, but it is certainly a completely wrong
transformation most of the time (the idea that one should be doing a test
against an absolute small value is very unlikely to be correct).