This is the mail archive of the
`gcc@gcc.gnu.org`
mailing list for the GCC project.

Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|

Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |

Other format: | [Raw text] |

*From*: Michael Matz <matz at suse dot de>*To*: Vincent Lefevre <vincent+gcc at vinc17 dot org>*Cc*: gcc at gcc dot gnu dot org*Date*: Fri, 3 Feb 2012 16:57:19 +0100 (CET)*Subject*: Re: weird optimization in sin+cos, x86 backend*References*: <CADn89gRRwQ5uPGCDMGZo28ofnAQsvU5PURKxPuvOPF1+ZbvO8g@mail.gmail.com> <CAFiYyc1oLgmP-bs2eyvW134SEzLONUxpcgiXMS4XnmamrUZ-9Q@mail.gmail.com> <Pine.LNX.4.64.1202031535030.25409@wotan.suse.de> <4F2BF9B6.20903@adacore.com> <20120203152858.GC5312@xvii.vinc17.org>

Hi, On Fri, 3 Feb 2012, Vincent Lefevre wrote: > > >No normal math library supports such an extreme range, even basic > > >identities (like cos^2+sin^2=1) aren't retained with such inputs. > > > > I agree: the program is complete nonsense. > > I disagree: there may be cases where large inputs can be meaningful. Very doubtful when those values are themself computed by some mean, in difference to being meant as test integer input. IMHO integer radians are already doubtful, and a rouding error of just half an ULP for these large numbers already mean wildy different integers and hence completely off reductions. > And it may be important that some identities (like cos^2+sin^2=1) be > preserved. Well, you're not going to get this without much more work in sin/cos. > > It would be useful to know what the intent was. > > If the user requested such a computation, there should at least be some > intent. Unless an option like -ffast-math is given, the result should be > accurate. > > 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. Btw, the correct results for sin are about .7021835074240, and cos about -.71199601256024, so the sum is about -.0098125051362. His math library didn't get these results in either way. Nevertheless it doesn't make sense to require such precision for these input for a math library intended to be used for normal means. If you want to have precise numbers use an arbitrary precision math library. Ciao, Michael.

**Follow-Ups**:**Re: weird optimization in sin+cos, x86 backend***From:*Vincent Lefevre

**References**:**weird optimization in sin+cos, x86 backend***From:*Konstantin Vladimirov

**Re: weird optimization in sin+cos, x86 backend***From:*Richard Guenther

**Re: weird optimization in sin+cos, x86 backend***From:*Michael Matz

**Re: weird optimization in sin+cos, x86 backend***From:*Robert Dewar

**Re: weird optimization in sin+cos, x86 backend***From:*Vincent Lefevre

Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|

Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |