Re: [Boost-users] unit test BOOST_CHECK_CLOSE absolute

I agree with that most of the time but this is not always true. Just imagine the case you compare lattitude, longitude. In this case, only absolute values make sense.
Relative tolerance will give me false bug report, I want a point to be equal to (0, 0) with a small absolute error and I don't care if it is -1e-15 or +1e-10 so BOOST_CHECK_CLOSE is not an option here and I have to use BOOST_CHECK_SMALL with the absolute difference. The problem with BOOST_CHECK_SMALL(fabs(x - expected_x), 1e-3); Is that when it fails with the message that does not print the values "x" and "expected_x" and does not say something like x(2.0) is not equal to "expected_x(0.0)" with an difference of 1e-3. I can probably write my own macro combining BOOST_TEST_MESSAGE() and some glues to obtain what I want but I was wondering if someone had the same problem and a solution. Thanks Renaud

Sure, 0deg East and 180deg East are physically the same, but it is a fact of floating point life that you can record/measure a point close to 0deg East to more precision than one near 180 East. This is why people always suggest using custom types (e.g. a currency type for finance) when this thread comes up.
Be careful using the naïve solution of something like
#define MY_TEST_ABS(x,y,tol,msg) BOOST_CHECK_MESSAGE( std::abs((x)-(y)) <
tol , build_test_abs_error_message(x,y,tol,msg) )
Here x and y are repeated in the macro expansion so when x = f(a,b,c) this
leads to subtle bugs or unexpected performance (f is called twice).
To do it properly you have to follow what is done for BOOST_CHECK_CLOSE and
a define a new predicate analagous to close_at_tolerance (found in
participants (2)
-
lepere renaud
-
Pete Bartlett