RE: [boost] test_fp_comparisons and rounding errors

From: Rozental, Gennadiy (gennadiy.rozental_at_[hidden])
Date: 2003-07-07 16:51:50

>  >What's most of the time needed is relative precision.
>  >
>  >So, numerical gurus: how can one express "a equals b within 
> 0.1%" over  >the whole range of floating point numbers? If 
> that can be done, it would  >be a nice useful routine.  >  
> >bool approximately_equal(double lhs, double rhs, double 
> relative_prec)  >{
>  >    // fill in here please :o)
>  >}
> 
> But it really doesn't seem that a test library is the right 
> home for such 
> functions. I think all the fp stuff should be removed from 
> Boost.Test, and 
> passed on as a challenge to the numerics experts.

Yes . It does not. But test library does not try to provide them. The only
thing it will try to provide is tool that given 2 FPT values and tolerance
checks that relative error does not exceed tolerance. I do not know how to
choose tolerance properly. It may be business requirement or come naturally
from type of computation. 

 
> After all, the user can always write:
> 
>    BOOST_CHECK( approximately_equal(...) );
> 
> --Beman

User could always use BOOST_CHECK for all kind of assertions. The reason
Boost.Test supply many other tool is to provide as many information as
possible. Above form wouldn't should mismatched values and this is most
important. We could've used generic BOOST_CHECK_PREDICATE, but it seems to
be too verbose for such simple and more or less widely used task as value
comparison. Also BOOST_CHECK_CLOSE supposed to have special logic to
demonstrate differences namely in FP numbers (it's not implemented yet). Two
different FP number may have the same default printed representation. That
may confuse the user.

In summary. The purpose of BOOST_CHECK_CLOSE is not to supply "smart" FP
numbers comparison algorithm, but convenient and concise tool that perform
simple comparison of relative error and show the error message as nice as
possible. 
  The error was to attempt to deduce the tolerance based on number of
arithmetic operations involved in calculation. I will eliminate that (it was
not that useful anyway, cause it's scope was limited only to arithmetic).

Gennadiy.