Bug?

[Dik T. Winter]

In article <10895 at riks.csl.sony.co.jp> diamond at riks. (Norman Diamond) writes:
 > In article <9986 at alice.UUCP> ark at alice.UUCP (Andrew Koenig) writes:
 > 
 > >Even if the == operator includes a fuzz factor, it's hard to imagine
(I may be obtuse, but what is the meaning of Even here?)
 > >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.
 > 
First off, there are many systems where (a-b)==0 while a and b are not equal
(there are less when you invoke the optimizer!).  On the other hand there
are many systems where (a-b)==0 implies that a and b are identical (IEEE
standard conforming machines come to the mind.)

The point is: how is the expression (a-b)==0 calculated?
1.  Optimized to a comparison of a and b.
1.1.The hardware does a direct comparison: (a-b)==0 implies a==b.
1.2.The hardware does a comparison by subtraction and does not
    know about partial underflow: (a-b)==0 does not imply a==b.
1.3.As 1.2, but partial underflow is allowed: (a-b)==0 implies a==b.
2.  Not optimized as under 1.
2.1.Hardware does not know partial underflow: like 1.2.
2.2.Hardware does know about it: like 1.3.
And I did not yet mention all (e.g. machines that recognize partial
underflow only in some circumstances; you can have: a*2.0=0.0 but
a+a!=0.0).

I agree with Mr. Koenig:
 > >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.
but non-sensible systems do exist.
-- 
dik t. winter, cwi, amsterdam, nederland
INTERNET   : dik at cwi.nl
BITNET/EARN: dik at mcvax