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). -- Vincent Lefèvre <vinc...@vinc17.net> - Web: <http://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
