
Boost : 
From: Douglas Gregor (doug.gregor_at_[hidden])
Date: 20050913 08:08:24
On Sep 13, 2005, at 4:38 AM, Martin Bonner wrote:
> Doug Gregor [mailto:dgregor_at_[hidden]] wrote:
>
>> I've traced through this, and the right "exp" is getting called. The
>> machine epsilon for long double is:
>>
>> 4.9406564584124654417656879286822137236505980261432476442558568250067
>> 550
>> 727020875e324
>>
>
> Are you sure that's right? That implies a 1074bit mantissa.
> That's a VERY
> long double! (It is also a rather odd sized one. In such a large
> type, I
> would expect the mantissa to be an exact number of bytes  or
> mantissa+sign
> to be an exact number of bytes).
>
> That value looks much more reasonable for the smallest nonzero
> value of
> long double.
>
> (I am assuming that by epsilon you mean the smallest values such that
> 1+epsilon != 1, rather than the smallest value such that epsilon > 0).
I discussed this with Marshall Clow offline and we eventually talked
with an Apple engineer. Marshall summarized the issue as:
"gcc 4 uses a "doubled double" format for long double (why? I
don't know), where there are two double values inside the long
double. For numbers that can be represented exactly (like, say 0 or
1), the "next value" is very, very close, because (I'm assuming) they
can denormalize the lower value, and get 1e324 type ranges. However,
for numbers that cannot be represented exactly, the "next value" is
on the order of 2^112 greater. Since epsilon is defined as the
difference between 1 and the "next value greater than one", they can
return a very, very small number here  and it is correct (but not
useful)."
AFAICT, for this floatingpoint format, the machine epsilon is truly
a useless value; we shouldn't be comparing against it in our tests
because it doesn't really reflect the precision of the floatingpoint
format.
Doug
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk