I feared as much. (In fact worse than I feared - you might like to add these to the static assert docs - I would have dropped into this trap :-(( )
Supplementary question:
What impact will it each of the following have on Darwin long double
(that I believe you have used)
Not really used, just tried to port Boost code to it, and maybe ended up knowing more than I wanted.
if fp comparisons includes: BOOST_STATIC_ASSERT(numeric_limits<FPT>::is_specialized);
and
BOOST_STATIC_ASSERT(numeric_limits<FPT>::is_iec559);
and
if (numeric_limits<FPT>::epsilon() <= (FPT)0) { // numeric_limits not correctly specilized! return false; // Better warning desirable. Throw? }
We discussed numeric_limits<FPT>::epsilon() and I think we can produce an intuitively useful (if not exact) value using the normal formula 2^(1-significands)
Yep. I don't think you'll ever find a value of numeric_limits<>::epsilon() <= 0 BTW, it's a very small positive value very close to zero on Darwin. BTW I added a useful little helper program to Boost.Config (called math_info) that prints out this kind of information - see http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/output/... for the Darwin results. As well as checking numeric_limits, it also looks for a couple of other gotchas I've fallen into: like the sqrt of a finite long double being infinity! That one takes a bit of head scratching until you realise that the library in question truncates all long doubles to doubles internally before calculating any math function (and yes the long double overloads are there, they're just not useful). HTH, John.