Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!ginosko!uunet!kddlab!titcca!sragwa!wsgw!socslgw!diamond
From: diamond@csl.sony.co.jp (Norman Diamond)
Newsgroups: comp.lang.c
Subject: Re: Bug?
Message-ID: <10895@riks.csl.sony.co.jp>
Date: 4 Oct 89 04:15:24 GMT
References: <19831@mimsy.UUCP> <15852@dartvax.Dartmouth.EDU> <364@capmkt.COM> <14758@bfmny0.UU.NET> <9986@alice.UUCP>
Reply-To: diamond@riks. (Norman Diamond)
Organization: Sony Computer Science Laboratory Inc., Tokyo, Japan
Lines: 21

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.

For example (which obviously generalizes), imagine a base-10 system
where exponents can range from -99 to +99.  Let:
  a == 0.100001e-99
  b == 0.100002e-99
Then obviously a != b.  But what happens when (a-b) is computed?
(a-b) --> (-0.000001e-99) --> (-0.100000e-104) --> (0.000000e-99).

-- 
Norman Diamond, Sony Corp. (diamond%ws.sony.junet@uunet.uu.net seems to work)
  The above opinions are inherited by your machine's init process (pid 1),
  after being disowned and orphaned.  However, if you see this at Waterloo or
  Anterior, then their administrators must have approved of these opinions.