From: John Maddock (john_at_[hidden])
Date: 2005-10-19 07:49:19
> BUT I _HAVE_ been working on some of the missing math functions by a
> 'wrap' of Stephen Moshier's Cephes C library.
>
> I have posted a 'work in progress' for those interested in math
> functions, specially for comment, at
>
> http://www.hetp.u-net.com/public/unitTestFunc1.cpp
Hi, Paul, going over the TR1 review comments I've only just looked at this
(sorry), I noticed you're using:
BOOST_CHECK((std::tr1::beta(3., 4.) -
1.6666666666666666666666666666666666666667E-2) <
numeric_limits<double>::epsilon());
There are probably a couple of issues: firstly you should feed the
(found_value-expected_value) part into std::fabs, otherwise any arbitrarily
small (or negative!) result will pass the test.
Next the < comparison should be a <= since the only way that
std::fabs(found_value-expected_value) < numeric_limits<double>::epsilon()
can be true is if
found_value == expected_value
when you think about it :-)
The way I handled this in the complex number additions in the TR1 submission
was to:
Define an acceptable fudge factor as a multiple of
numeric_limits<T>::epsilon(), I'd be very surprised if all the special
functions are actually accurate to one epsilon ?
Then convert the fudge factor to a percentage (multiply by 100) and use
BOOST_CHECK_CLOSE (that way you get both expected and found values printed
out if there is an error), see libs/math/test/log1p_expm1_test.cpp for some
examples.
I haven't looked into it yet, but I believe there are some platforms where
epsilon is artificially small (for long double on MacOS X), so using
numeric_limits<T>::digits() to create your own epsilon may actually be the
way to go for testing.
HTH,
John.