
Boost : 
From: Martin Bonner (martin.bonner_at_[hidden])
Date: 20050913 04:38:29
Doug Gregor [mailto:dgregor_at_[hidden]] wrote:
>> Somebody wrote:
>>>> It looks like some code isn't handling the improved "long double"
>>>> type very well.... (With Mac OS X Tiger 10.4 and GCC 4, the
>>>> "long double" type is finally distinct and bigger than "double".
>>>> The preTiger warnings about not using "long double" are
>>>> obviously removed. But it looks like the "double" version of
>>>> "exp" is being used. Taking a quick look at a system "math.h"...
>
> I've traced through this, and the right "exp" is getting called. The
> machine epsilon for long double is:
>
> 4.9406564584124654417656879286822137236505980261432476442558568250067550
> 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).
>
> There's no *way* we'll get that much accuracy out of the C library's
> sin/atan/cos/etc. Here's the result of a little program that prints
> out atan(1), 4*atan(1), and sin(4*atan(1)). There isn't a large enough
> improvement in precision from "double" to "long double":
>
> atan(1) with float = 0.785398185253143310546875
> 4*atan(1) with float = 3.1415927410125732421875
> sin(4*atan(1)) with float =
> 8.74227765734758577309548854827880859375e08
> atan(1) with double =
> 0.78539816339744827899949086713604629039764404296875
> 4*atan(1) with double =
> 3.141592653589793115997963468544185161590576171875
> sin(4*atan(1)) with double =
> 1.224606353822377258211417938582599163055419921875e16
> atan(1) with long double =
> 0.7853981633974483096282022398515465511081856675446033477783203125
> 4*atan(1) with long double =
> 3.14159265358979323851280895940618620443274267017841339111328125
> sin(4*atan(1)) with long double =
> 5.42101086242752217003726400434970855712890625e20
If long double is actually 80 bits (which is the usual Intel
interpretation), that looks plausible.
> I don't even think that we can call this a platform bug; we just can't
> expect the C library routines to have that kind of precision.
If long double really is >1kbits, I don't see why the C runtime shouldn't
support them.
> I think
> we should consider long double tests on this platform bogus and
> disable them.
 Martin Bonner Martin.Bonner_at_[hidden] Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 441434
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk