🚀 go-pugleaf

>From article <129...@sun.Eng.Sun.COM>,
by lin...@adapt.Sun.COM (Peter van der Linden):
> Kees Huizing - Eindhoven Univ of Techn - The Netherlands,  wants to know:
>> the equality operator "=" does not (do) on reals what it pretends to do.  
>> I accept that it cannot detect perfect equality of reals, but what it
>> could do is detect equality up to some representation dependent accuracy.   
> 
> A very reasonable question Kees!  A number of years ago, a gentleman by the
> name of Dijkstra, ... had the very same thought ...
> 
> The experiment was soon deemed a failure when it was found that this had
> the inadvertent and unwanted side effect that comparison was no longer
> transitive.  I.e. if A equalled B, and B equalled C, a program could not
> conclude that A = C !

It's worse than that!  The PLATO system at the U. or Illinois implemented
comparison this way.  They had good motives:  They didn't want to have to
explain to non-numerically-literate users why, for example, 0.1*100.0
wasn't equal to 10.0.

It avoided such complaints, but it produced awful results when you tried to
code many standard numerical algorithms.  For example:

   If the equality test is modified as above, but the > and < tests
   are unmodified, it is possible that two of A=B, A<B and A>B may
   be true at the same time (although only one of A<B or A>B may be
   true).  This leads to a real mess.

   If you modify all comparison operators so that only one of A<B,
   A=B, or A>B will be true, comparisons are suddenly misleading.
   A<=B means (A<B or A=B) and it is consistent with not(A>B), but
   suddenly, there are values of A and B such that A<=B is reported
   as true, but in fact, A is slightly greater than B.  As a result,
   there are values of A and B where A<=B is reported to be true,
   ((A-B)*10)>0 is also reported as true.