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
Message-ID: <5723@brl-smoke.ARPA>
Date: Sun, 5-Apr-87 18:47:35 EST
Article-I.D.: brl-smok.5723
Posted: Sun Apr  5 18:47:35 1987
Date-Received: Thu, 9-Apr-87 01:48:06 EST
References: <15958@sun.uucp> <5716@brl-smoke.ARPA> <1283@dataio.Data-IO.COM>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 20
Keywords: C Floating Point

I suppose I should have made it clear that I was discussing
the issue in terms of portable programming practice.

Tests for float-point equality with particular bit patterns
is clearly very machine-specific.  Walter Bright further
assumed he would not get in trouble due to register/memory
width differences such as I explained in an earlier example.
Seldom are floating-point values merely picked up and passed
around; much more often they are computed quantities that
inherently have "fuzz" attached to them.  It is the "fuzz"
that makes floating-point equality testing so problematic.

Certainly if you can count on specific behavior for your
system then you might find ways to exploit it.  I try to
avoid writing code like that (except in the special case
where I'm implementing the run-time system, or similar
circumstances where the gain outweighs the disadvantages).
I doubt that I'd trust the C compiler to in future releases
not change the code it generates for a particular source
construct, though.