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.
