|
Boost : |
From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2003-07-09 05:00:19
> > There is BOOST_CHECK_PREDICATE
> >
> Yes, I know.
> My point was that with BOOST_CHECK_EQUAL_NUMBERS() the test library
> could output something readable of the form:
>
> "numbers x and y are not approximately equal"
>
> It could even add to the output something of the form:
>
> " according to " << Pred ;
This is what BOOST_CHECK_CLOSE is doing basically.
> > By default, the Test library provides relative error comparator, which
is
> > according to my understanding is more correct.
> >
> But there is no such thing as a "more correct" way to compare
> FP values in the context free level of a test library.
> You know already that relative errors have to be scaled to be
> meaningful, but choosing the right scaling is the complex.
> A default semantic that simply scales epsilon() times any of the
> arguments will be simply unusable for most practical tests
> because actual errors will easily exceed that; yet OTOH,
> suppling a factor to increase the scaling will mainly lead users
> to the problematic Illusion of Simplicity that brought us
> to this discussion.
That part of interface I propose to eliminate. User will aonly be able to
define a tolearance as it is.
BOOST_CHECK_CLOSE( a, b, 1e-05 ); // 1e-05 is good enough for my practiacal
purposes
> A comparison based on absolute errors is pesimistic, but for unbiased
> comparisons it often results on what is expected, much more often
> that relative-error based comparisons.
> It isn't smart but is easy to understand.
For majority of simple cases (not very big, nor very small values) they
should behave similarly. For egde cases relative error comparison produces
better results IMO
Gennadiy.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk