RE: 1.5.24: sin() bug

["Dave Korn" <dave dot korn at artimi dot com>]

On 29 August 2007 18:07, Brian Dessent wrote:

> Dmitry Karasik wrote:
> 
>> #include <math.h>
>> #include <stdio.h>
>> int main( int argc, char ** argv)
>> {
>>         double g = (double) 3.1415926535897900074;
>>         printf("sin(%.10g)=%.10g\n", g, sin(g));
>> }
>> 
>> output is :
>> 
>> sin(3.141592654)=3.231089149e-15
>> 
>> whereas all other sin() implementation I could find ( freebsd, linux,
>> msvc) report this: 
>> 
>> sin(3.141592654)=3.231085104e-015
>> 
>> the difference is in 7th digit, and is significant for double precision.
> 
> This appears to be due to an approximation in __kernel_sin in which if
>> x| < 2**-27 the approximation sin(x) ~ x is used.

  Since when was pi less than 2^-27?

> In any case this is more of a newlib issue than a Cygwin issue as we are
> just a consumer of this code, so followups should go to the newlib list.

  I'd just like to point out that I got the exact same result as cygwin
supplies on a recent linux box:

  On cygwin, I get:

/tmp $ ./sin.exe
sin(3.141592654)=3.231089149e-15

... whereas on linux (x86_64), I get ...

[dk@ucho gxlinux-ent]$ ./sin 
sin(3.141592654)=3.231089149e-15

... and with mingw:

$ ./sin.exe 
sin(3.141592654)=3.231085104e-015

  I think it may be an artefact of FP precision and/or rounding mode, but I'd
need to do more experiments to make sure.  OTOH it could be an artifact of the
printf %g specfier.  Like I said, more experimentation is needed!


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....