floating-point comparisons illegitimate?

[Tom Pennello]

> From ucscc!uunet.UU.NET!validgh!validgh.com!dgh Fri Mar 15 08:43:19 1991
> 
> 
> While in general I don't think programmers should expect 
> 	A = expr
> 	if (A .eq. expr)
> to always be true, I don't see any reason to expect
> 	A = B
> 	if (A .eq. B)
> to fail.  
When first learning to program fortran in 1971, I was told that to write
	if (a .eq. b)
with floating-point a and b was a program error due to intrinsic
precision problems with floating point.  One should always write
	if (abs(a-b) < tolerance)
for suitably small tolerance.  I have encountered this problem in two
places over the years.  First, in a square root routine that looked like

	for (n = 50; c != cl && n--;) {
	   y = y - c;
	   cl = c;
	   c = (y - x / y) / 2.0;
	   }

which always ran 50 iterations because c never equaled cl; the compiler
kept c in an extended x87 register whereas cl was in memory.  So our
more aggressive optimizing compilers caused this code to run horribly
slow, whereas our less aggressive compilers had both c and cl in memory,
and the loop finished in just a few iterations.

In the second case, using a weitek 1167, the issue was not precision
of registers, but precision of computation, and the tradeoff between
precision and speed.
Here the computation a/b was done
with different code in two different locations in a program, and the
test was made to see if the two results were the same (this wasn't
checking accuracy; it was just testing for some condition).  The results
were never the same and the program failed.  It is because in one case
the compiler was able to multiply by the reciprocal of b, and in the
other case was not able to do so (the details of why aren't interesting).
This generated faster code where the reciprocal was used, 
and the customer was happy; however the
"bug" took me hours to find for him.  We had to turn off the reciprocal
optimization for his program.  So here we find that customers that are willing
to tolerate some imprecision in trade for speed certainly buy into
problems with writing (a .eq. b).
(Believe me, this guy wanted speed:  it would take 6 months on a vax, 
but he cut it down to a few days on half a dozen compaqs with 1167s.) 

My personal conclusion:  never write (a .eq. b).