Re: [boost] Boost regression notification (2005-09-03 [HEAD])

From: Doug Gregor (dgregor_at_[hidden])
Date: 2005-09-12 12:01:07

On Sep 7, 2005, at 2:41 PM, Marshall Clow wrote:

> At 3:41 PM -0500 9/6/05, Doug Gregor wrote:
>> On Sep 5, 2005, at 12:11 PM, Daryle Walker wrote:
>>
>>>  On 9/3/05 1:00 PM, "Douglas Gregor" <dgregor_at_[hidden]> wrote:
>>>
>>>>  Boost regression test failures
>>>>  ------------------------------
>>>>  Report time: 2005-09-03T05:00:17Z
>>>  [SNIP]
>>>>  Detailed report:
>>>>   
>>>> http://engineering.meta-comm.com/boost-regression/CVS-HEAD/ 
>>>> developer/
>>>>  issues.ht
>>>>  ml
>>>  [SNIP]
>>>>  |math|
>>>>  octonion_test:  gcc-4_0-darwin  gcc-4_0-darwin
>>>>  quaternion_test:  gcc-4_0-darwin  gcc-4_0-darwin
>>>>  special_functions_test:  gcc-4_0-darwin  gcc-4_0-darwin
>>>  [TRUNCATE]
>>>
>>>  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'm not sure there is a "long double" overload of "exp", just  
>>> "expl".)
>>
>> Sounds like we need to do some specializing for Tiger's GCC 4.0. Would
>> you submit a patch to fix these problems?
>
> in <cmath>, rather than <math.h>, there is:
> 	  long double exp(long double __x);

I've traced through this, and the right "exp" is getting called.  The  
machine epsilon for long double is:

         
4.9406564584124654417656879286822137236505980261432476442558568250067550 
727020875e-324

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.74227765734758577309548854827880859375e-08
        atan(1) with double =  
0.78539816339744827899949086713604629039764404296875
        4*atan(1) with double =  
3.141592653589793115997963468544185161590576171875
        sin(4*atan(1)) with double =  
1.224606353822377258211417938582599163055419921875e-16
        atan(1) with long double =  
0.7853981633974483096282022398515465511081856675446033477783203125
        4*atan(1) with long double =  
3.14159265358979323851280895940618620443274267017841339111328125
        sin(4*atan(1)) with long double =  
-5.42101086242752217003726400434970855712890625e-20

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. I think  
we should consider long double tests on this platform bogus and disable  
them.

        Doug