Bug 10709 - sin() returns incorrect rounding
Summary: sin() returns incorrect rounding
Status: RESOLVED FIXED
Alias: None
Product: glibc
Classification: Unclassified
Component: math (show other bugs)
Version: 2.10
: P2 normal
Target Milestone: ---
Assignee: Ulrich Drepper
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-09-30 12:50 UTC by Paul Zimmermann
Modified: 2014-07-01 06:45 UTC (History)
3 users (show)

See Also:
Host: x86_64-redhat-linux
Target: x86_64-redhat-linux
Build: x86_64-redhat-linux
Last reconfirmed:
fweimer: security-


Attachments
test case (212 bytes, text/x-csrc)
2009-09-30 12:57 UTC, Paul Zimmermann
Details
Patch for sine (869 bytes, patch)
2011-07-21 07:17 UTC, Andreas Jaeger
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Paul Zimmermann 2009-09-30 12:50:53 UTC
for the double precision number closest to 2.522464e-1, the glibc sin() function
returns 2.4957989804940914e-01 (when printed to 17 digits, which identifies
uniquely double-precision numbers), whereas the correct rounding to nearest is
2.4957989804940911e-01.

According to glibc/sysdeps/ieee754/dbl-64/s_sin.c, the result should be
always correctly rounded.
Comment 1 Paul Zimmermann 2009-09-30 12:57:37 UTC
Created attachment 4236 [details]
test case

compile with -fno-builtin to ensure the sin() call is not folded at
compile-time
Comment 2 Paul Zimmermann 2009-09-30 13:07:33 UTC
This bug is analyzed and a fix is proposed at
<http://www.loria.fr/~zimmerma/papers/bug10709.pdf>.

In short, it suffices to replace the line:
return (res==res+1.025*cor)? res : slow1(x);
in file glibc/sysdeps/ieee754/dbl-64/s_sin.c by:
return (res==res+1.096*cor)? res : slow1(x);

Paul Zimmermann
Comment 3 Andreas Jaeger 2011-07-12 14:18:33 UTC
Patch:
http://sourceware.org/ml/libc-alpha/2011-07/msg00030.html
Comment 4 Ulrich Drepper 2011-07-20 20:09:05 UTC
(In reply to comment #3)
> Patch:
> http://sourceware.org/ml/libc-alpha/2011-07/msg00030.html

First, the patch contains unrelated changes.

Second, on what basis is this magic new factor chosen?  If this is just empirical, why should I trust that value?
Comment 5 Paul Zimmermann 2011-07-20 20:48:04 UTC
(In reply to comment #4)
> 
> Second, on what basis is this magic new factor chosen?

see the pdf at comment #2.

Paul Zimmermann
Comment 6 Andreas Jaeger 2011-07-21 07:17:30 UTC
Created attachment 5854 [details]
Patch for sine
Comment 7 Andreas Jaeger 2011-07-21 07:18:20 UTC
I send the wrong patch to the mailing list, have attached now the proper one.
Comment 8 Ulrich Drepper 2011-10-29 18:09:53 UTC
I checked in the patch.