Re: weird optimization in sin+cos, x86 backend

[Michael Matz <matz at suse dot de>]

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.