Bug?

[Rob Carriere]

In article <1989Sep29.144716.20921 at brutus.cs.uiuc.edu> coolidge at cs.uiuc.edu
writes: 
>brent at capmkt.COM (Brent Chapman) writes:
>>earleh at eleazar.dartmouth.edu (Earle R. Horton) writes:
>># [...]  Instead of
>># 	( a == b )
>># use
>># 	( ( a < b + MINDOUBLE ) && ( a > b - MINDOUBLE ) )
>># 
>># MINDOUBLE is in <values.h>.
>>[...]  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.

Worse yet, in some situations you may want a value significantly larger than
MINDOUBLE for your fuzzing.  This may be because of the numerical conditioning
of your algorithm, or inaccuracies in your input data, or simply because
you don't need a high-precision answer.  The compiler cannot possibly foresee
all these circumstances.  If you object to the clarity of the code, write a
macro or function of the form

int is_equal( double x, double y, double tol );  /* [1] */

that does the evaluation for you.  But whatever you do, *never* assume a
simple equality test on floats or doubles will work.  And *always* be able to
justify the value of the tolerance you used.  If you don't do those things,
you don't know what your program's output means.

SR