Re: Formal review: New Boost.Test Library

From: Dave Gomboc (dave_at_[hidden])
Date: 2001-12-06 18:42:09

> > Using a fixed epsilon is bogus for the numerical applications
> > that I am familiar with.  What we really need to do is make
> > the third argument a binary predicate returning bool whose
> > operator() is called with the first two arguments.  That wasn't
> > a great explanation, but I hope you get what I mean.
> >
> > Dave Gomboc
>
> What algorithm you proposing? Or al least examples?

I was not proposing the use of a specific algorithm for floating-point
equality comparison (or any other true/false comparison).  I was
proposing that the algorithm used to make the decision be provided as an
argument to the code that is doing the check.  Someone else caught onto
what I meant and described it (better, I guess :-) as

> BOOST_CHECK_PREDICATE2( left, right, binary_predicate)

They gave a unary version also.  In fact, now it seems even better to
put the predicate _first_, then the arguments that will be filled into
the predicate afterward.  At least, it would be, if we have some nice
variable-argument stuff.  Then:

BOOST_CHECK_PREDICATE (nullary_predicate)
BOOST_CHECK_PREDICATE (unary_predicate, a)
BOOST_CHECK_PREDICATE (binary_predicate, a, b)
BOOST_CHECK_PREDICATE (ternary_predicate, a, b, c)
...

would all work (and return bool), no need for ugly differences depending
on the number of arguments.

> In simple case fixed epsilon could work. In more complex cases
> having final compared values may not be enouph either.

Absolutely.  The tolerance depends upon the operations and the arguments
one is performing.  It's not sufficient to have one (or even a few)
fixed types of comparisons, that's why it should be possible to supply
an arbitrary test.  If it is a simple case, then the simple fixed
epsilon test can be provided.  Plus, now these common predicates can be
provided outside of Boost.Test (they can be in some math area instead).

Dave Gomboc