Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!cbatt!ihnp4!homxb!houxm!mhuxt!mhuxm!mhuxo!ulysses!allegra!mit-eddie!husc6!seismo!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.UUCP
Newsgroups: comp.lang.c
Subject: Re: C and Floating Point (LONG)
Message-ID: <5725@brl-smoke.ARPA>
Date: Sun, 5-Apr-87 19:36:10 EST
Article-I.D.: brl-smok.5725
Posted: Sun Apr  5 19:36:10 1987
Date-Received: Thu, 9-Apr-87 01:49:12 EST
References: <15958@sun.uucp> <5716@brl-smoke.ARPA> <532@omepd>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 41

In article <532@omepd> jimv@omepd.UUCP (Jim Valerio) writes:
>Doug, I believe that you are mistaken in a number of points you make
>in your rejoinder to Dave Hough's note here.

Thanks for the extended discussion, Jim.  I won't repeat the points
I made before; however I must note that about half of the Spice
examples of use of floating == were benign, but the other half fell
into the pitfalls that make me so distrustful of floating ==.  For
the most important example, simply checking that the divisor is non-
zero does NOT guarantee against overflow in the subsequent division.
Truly robust floating-point code must be much more carefully crafted
than that.

A simple list of how floating == has been used (e.g. in Spice) is
not the same thing as a lists of contexts in which its use is safe.

It's also not very surprising to learn that Mr. Hough was one of the
people we have to "thank" for the IEEE floating-point standard.
Many of the qualified people I've discussed the IEEE standard with
have been very dissatisfied with it.  My particular gripe is that it
tries to legitimatize arithmetic with nominally invalid operations
(producing extended "values" such as plus or minus "infinity"); this
merely encourages those programmers who weren't taking sufficient
pains with their algorithms to run off and produce even more
meaningless results ("The hardware supports it, it must be okay.").

I've been burned too many times by floating-point computations that
misbehave when pushed near their extremes.  Unfortunately I can't
offer a simple recipe for avoiding such problems, other than to
know what can go wrong and to think carefully when designing the
algorithm.  The only simple formulas I know of that are right most
of the time are "watch out when dividing", "use atan2(), not atan()",
"consider normalizing", and "be suspicious of any test for equality".
I wish I had better, more specific rules, but I don't (and I have
read many of the references Mr. Hough gave; they don't help much).

The reason I'm not actually going to propose removal of floating
== from the ANSI C standard is that it doesn't solve the real
problem, which is that most programmers are insufficiently aware
of pitfalls in floating-point arithmetic.  Neither a change in ANSI
C nor the IEEE floating-point standard directly address this problem.