From: Martin Bonner (martin.bonner_at_[hidden])
Date: 2005-09-13 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 pre-Tiger 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:
Are you sure that's right? That implies a 1074-bit 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 non-zero value of
(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 =
> atan(1) with double =
> 4*atan(1) with double =
> sin(4*atan(1)) with double =
> atan(1) with long double =
> 4*atan(1) with long double =
> sin(4*atan(1)) with long double =
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
> 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