
Boost : 
From: John Maddock (john_at_[hidden])
Date: 20051019 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.unet.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.6666666666666666666666666666666666666667E2) <
numeric_limits<double>::epsilon());
There are probably a couple of issues: firstly you should feed the
(found_valueexpected_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_valueexpected_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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk