Re: [boost] Boost Test Library: general floating point comparisons

From: John Maddock (john_at_[hidden])
Date: 2007-02-14 04:19:29

Dave Steffen wrote:
> Hi folks,
>
> This is probably a question aimed at Gennadiy Rozental, but it may be
> of interest to the community in general.
>
> We've been using the boost test library for about a year and a half
> now, and are happy customers.  I'm revamping our unit test framework
> (e.g. revisiting the way we use boost test), and am specifically
> looking at the floating point comparisons.
>
> One thing that I'm changing / hacking is the use of percentages to
> specify tolerance.  We usually want answers to agree to (say) 1 part
> in 10^-12, and remembering to multiply or divide that by 100 is
> annoying.  To this end, I'm defining our own set of comparison
> functions and macros, still using the stuff in ttdetail (e.g. fpt_abs
> and save_fpt_division).

How about:

#define BOOST_CHECK_ACCURACY(x, y, acc) BOOST_CHECK_CLOSE(x, y, acc*100)

Of course then the error messages aren't very readable :-(

Like you I think the whole persentage thing was a big mistake: even though I 
know what the API does and use it all the time, forgetting to convert to a 
persentage is the by far the most common fowl-up.

> Fine.  Now, we want to be able to compare more complicated
> mathematical objects, such as vectors and matrices.
>
> After some thought, we decided the responsibility for providing such
> functions is the responsibility of the mathematical object, not the
> unit test framework.  That is to say, a function "relative difference
> between matrices" should be in Matrix.h, not some unit test thing.
>
> Which leads to the idea of Matrix.h #including
> "boost/test/floating_point_comparison.hpp", which strikes me as rather
> odd.  My first impulse was to copy/pull the relevent code out of
> floating_point_comparison.hpp and stick it in some more convenient
> place, where mathematical objects could use those functions to
> implement their own comparision functions.
>
> Might this be a common idiom?  Might we consider factoring these
> floating point comparison functions (not the BOOST_CHECK_CLOSE macro,
> but the functions it uses) out into a separate library?  Any comments
> on my approach?

I think it is a common idiom, I had to jump though similar hoops for testing 
complex numbers, Genadiy's idea of using BOOST_CHECK_PREDICATE might work as 
well though (you could wrap the code in your own macro to simplify usage as 
well).

John.