Bug?

[John Coolidge]

brent at capmkt.COM (Brent Chapman) writes:
>earleh at eleazar.dartmouth.edu (Earle R. Horton) writes:
># It is in general bad practice to apply an equality test to the result
># of a computation.  Instead of
># 	( a == b )
># use
># 	( ( a < b + MINDOUBLE ) && ( a > b - MINDOUBLE ) )
># 
># MINDOUBLE is in <values.h>.
>Yeah, _right_.  Nice, clear, concise code there.  Why shouldn't I reasonably
>expect the compiler to do this for me?

Because it can produce very non-intuitive results. For instance, if the
compiler were to do it automatically it's entirely possible that
	if( ( a == b ) && ( b == c ) && (a != c) ) 
		printf( "What happened?\n" );
would print "What happened?" a lot. The reason is that a could well
equal b within the fuzz factor, and b could equal c, but a could be
2*MINDOUBLE away from c's value and hence not be equal.

That's why compilers don't automatically generate code to 'fix' problems
like this: because it might cause far bigger problems for people
doing lots of floating point ops. In general floating point is a
big problem --- equality tests on floating point numbers are a bad
idea in most languages. Also, things like a*(b+c) often don't equal
a*b+a*c, a*(b*c) is often unequal to (a*b)*c, and so on.

Followups to comp.lang.c, because this is more a C language issue.
It's certainly not specific to A/UX anymore.

--John

--------------------------------------------------------------------------
John L. Coolidge     Internet:coolidge at cs.uiuc.edu   UUCP:uiucdcs!coolidge
Of course I don't speak for the U of I (or anyone else except myself)
Copyright 1989 John L. Coolidge. Copying allowed if (and only if) attributed.
You may redistribute this article if and only if your recipients may as well.