(A .eq. B) or (ABS(a-b) .LT. tolerance) ?

[David G. Hough on validgh]

A reasonable model of computer arithmetic would confirm the wisdom of
	(ABS(a-b) .LT. tolerance)
as a test for close-enough when a and b are computed by different means,
for which error bounds tell you how big "tolerance" must be.

But if a and b are the same type,
and computed by direct assignment, one from the other, then it's kind of hard
to imagine what "tolerance" to use.  In IEEE arithmetic, there is no
reason to use such a complicated test in lieu of a .eq. b.

IEEE extended precision arithmetic is supposed to be like normal arithmetic,
except better in computing anonymous expressions in the sense of providing
better error bounds and better immunity to exponent spill.
If, as has been the case in most implementations so far,
extended is better some of the time and worse some of the time,  
then it's implemented wrong.

I had the pleasure of attempting to microcode fuzzy comparison and fuzzy
convert to integer for the Tektronix 4061, following a language feature
of 4051 Basic that came from HP Basic or APL or somewhere.  I soon 
discovered that no efficient implementation could be efficiently documented,
and vice versa.   As my colleague Tom Almy said, "fuzzy comparison is a 
fuzzy concept."  I was able to convince that project to remove the feature
from the instruction set.  Like lots of superficially user-friendly features,
it obscures the initial difficulties in order to lure you in deep enough
to get really stuck.  If you need analytical or computational error bounds,
it doesn't help.