Boost logo

Boost :

From: Fernando Cacciola (fcacciola_at_[hidden])
Date: 2003-07-09 13:35:25


"Gennadiy Rozental" <gennadiy.rozental_at_[hidden]> escribió en el mensaje news:begp29$u8n$1_at_main.gmane.org...
> > > 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.
>
Yes, that's the point.
What I proposed is that the user can combine the macro with
the comparator (I changed the macro name), becuase the comparison
method is often application specific.
I suggested to have an abosulte error comparator class as a default,
but not as a fixed method inside the macro.
The problem with any fixed scheme is that it can't be general enough, and
the test library is highly general.

I'm not sure if any fixed comparison method should be supplied at all.
I would choose between my proposal, were specific targets can supply
their own comparators, or not having fp comparison at all in the test
library itself.

>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

No. It is not a matter of value magnitude or edge/non-edge cases.
It is a matter of the number and type of operations performed yielding
the values to be compared. This is why the best method is highly
domain specific.

Fernando Cacciola


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk