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.