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).
#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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk