On 3 February 2012 21:48, Vincent Lefevre <vincent+...@vinc17.org> wrote: > On 2012-02-03 17:44:21 +0100, Michael Matz wrote: >> Hi, >> >> On Fri, 3 Feb 2012, Vincent Lefevre wrote: >> >> > > > For the glibc, I've finally reported a bug here: >> > > > >> > > > http://sourceware.org/bugzilla/show_bug.cgi?id=13658 >> > > >> > > That is about 1.0e22, not the obscene 4.47460300787e+182 of the >> > > original poster. >> > >> > But 1.0e22 cannot be handled correctly. >> >> I'm not sure what you're getting at. Yes, 1e22 isn't handled correctly, >> but this thread was about 4.47460300787e+182 until you changed topics. > > No, the topic is: "weird optimization in sin+cos, x86 backend". > But actually, as said by Richard Guenther, the bug is not the > optimization, but the behavior of the sincos function. What I'm > saying is that this wrong behavior can also be seen on 1.0e22 > (at least with the glibc, and any implementation that uses the > fsincos x86 instruction). > >> > > If you want to have precise numbers use an arbitrary precision math >> > > library. >> > >> > This is double precision. An arbitrary precision math library (even >> > though I develop one) shouldn't be needed. >> >> But the reduction step needs much more precision than it currently uses to >> handle inputs as large as 4e182 correctly. > > No, the range reduction can cleverly be done using the working > precision (such as with Payne and Hanek's algorithm). > From what I can see, on x86_64, the hardware fsin(x) is more accurate than the hardware fsincos(x). As you gradually increase the size of X from 0 to 10e22, fsincos(x) diverges from the correct accurate value quicker than fsin(x) does.
So, from this I would say that using fsincos instead of fsin is not a good idea, at least on x86_64 platforms. So, I suggest that: 1) sin() uses fsin 2) cos() uses fcos 3) sincos() uses fsincos (might be a contentious point?) 4) If a program is using sin(x) close to cos(x), do not optimize it to a sincos()
