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
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.