Path: utzoo!attcan!uunet!ibmpa!ghoti!lmb
From: lmb@ghoti.uucp (Larry Breed)
Newsgroups: comp.lang.c
Subject: Re: Bug?
Message-ID: <2577@ibmpa.UUCP>
Date: 14 Oct 89 01:26:19 GMT
References: <19831@mimsy.UUCP> <15852@dartvax.Dartmouth.EDU> <364@capmkt.COM> <14758@bfmny0.UU.NET> <9986@alice.UUCP> <10895@riks.csl.sony.co.jp>
Sender: news@ibmpa.UUCP
Reply-To: lmb@ibmsupt.UUCP (Larry Breed)
Organization: IBM AWD Palo Alto
Lines: 24

In article <10895@riks.csl.sony.co.jp> diamond@riks. (Norman Diamond) writes:
>In article <9986@alice.UUCP> ark@alice.UUCP (Andrew Koenig) writes:
>
>>Even if the == operator includes a fuzz factor, it's hard to imagine
>>a sensible implementation in which (a-b)==0 is true unless a and b
>>are truly identical.
>
>Sorry Mr. Koenig, it's easy to imagine.  Every hardware floating-point
					  ^^^^^
>system and most software ones have situations where (a-b)==0 but a != b.
>
> ...
>(a-b) --> (-0.000001e-99) --> (-0.100000e-104) --> (0.000000e-99).

Wrong.  ieee 754/854 floating-point hardware has 'gradual underflow' that retains 
significand values in a denormalized form if normalizing would cause exponent
underflow.  In your example, -0.000001e-99 would be retained as is. 
What you (Norm) say is true of most older fp implementations, but
there are an awful lot of good ieee 754 machines out there these days.
What you (Andy) say is true of ieee 754 machines, but there are an awful
lot of older fp implementation out there still.
Disclaimer: Don't blame my employer, blame:
Larry Breed			(415) 855-4460
uucp: uunet!ibmsupt!lmb		inet: ibmsupt!lmb@uunet.uu.net