This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug math/13381] rounding problem wih sincosl
- From: "gastineau at imcce dot fr" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: Fri, 23 Dec 2011 11:20:24 +0000
- Subject: [Bug math/13381] rounding problem wih sincosl
- Auto-submitted: auto-generated
- References: <bug-13381-131@http.sourceware.org/bugzilla/>
http://sourceware.org/bugzilla/show_bug.cgi?id=13381
--- Comment #11 from gastineau at imcce dot fr 2011-12-23 11:20:24 UTC ---
The documentation does not mention that the algorithm is different and that
sincosl could return a different result that cosl and sinl.
So I think that the documentation may be updated to specify that result could
be differents.
Le 23/12/11 12:01, vincent-srcware at vinc17 dot net a Ãcrit :
> http://sourceware.org/bugzilla/show_bug.cgi?id=13381
>
> --- Comment #10 from Vincent LefÃvre<vincent-srcware at vinc17 dot net> 2011-12-23 11:01:30 UTC ---
> I agree that this bug here can be seen as invalid, as long as the error is not
> greater than the documented error bound. It's even "normal" that sincosl
> doesn't return the same result as sinl and cosl, as the algorithm is different
> and the goal of such a hardware implementation is to provide a result quickly,
> though not highly accurate.
>
> Now, there could be two valid related bugs:
>
> 1. As these hardware functions seem to be completely wrong for large arguments
> (on both Intel and AMD), the glibc should not use them in such cases. At least,
> it should provide an option so that it can be compiled to use a software
> implementation. Note: though relatively fast hardware range reduction is
> possible, I'm sure that was the intent of these hardware instructions when they
> were introduced in the 80's (?). I mean that blindly using these hardware
> instructions in a system library (i.e. without knowing the application) could
> be seen as a misuse of these instructions.
>
> 2. The IEEE 754-2008 standard recommends correct rounding. So, a RFE to have
> correct rounding would be valid, but perhaps wontfix for the extended precision
> (not standard, its primary goal being to ease accurate implementations of the
> double precision). For the double precision, unless this has been fixed, sincos
> is affected by this problem, which affects code using sin and cos compiled by
> GCC; see
>
> http://www.vinc17.net/research/slides/sieste2010.pdf
>
> Slides 11-15 for this point.
>
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.