From: John Maddock (john_at_[hidden])
Date: 2006-02-11 13:01:05
> 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/dmcgrath-bin-boost-status-math_info-test-gcc-4_0-darwin-debug.html
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.