[Haskell-cafe] Some More Sinus Results

[David Roundy]

On Sat, Nov 10, 2007 at 06:56:23PM +0100, Hans van Thiel wrote:
> Thanks to all who've replied; Carl's explanation in particular was very
> interesting. So the precision, suggested by the many decimals in the
> 'show', is not the actual precision the user should 'count on'. If you
> take 1/60 of a degree to be approximately 0.0003 radians, you should not
> use sin for smaller values. In all cases the actual precision of sin
> appears to be 4 to 5 decimals, and results should be rounded to that
> before using them. Now I'm wondering about cos, tan and also the
> inverses, asin etc. :-)

What you're observing in these calculations is not so much the inaccuracy
of sin as the inaccuracy of pi.  Pi is an irrational number, so the Double
constant pi is only an approximation, with an error probably around 3e-16
(1e-16 fractional error).  Simple calculus tells you that the error in
sin(pi) will thus be around:

sin(truepi+3e-16) ~ 0 + 3e-16

from which we conclude that the error in pi isn't really as bad as we'd
naively expect.

For small epsilon, we can see that

sin((1+/-epsilon)*(truepi+3e-16)) ~ 0 +/- pi*epsilon + 3e-16.

which roughly explains your data quoted.

Results of sin should *not* be rounded before using them, unless you really
want a less accurate answer.

Users who "count on" a particular precision, should not be using computers
to do their arithmetic.


The blog article on the accuracy of sine glossed over the relevant issue:
that there's no point in getting better accuracy.  It points out that
sin(pi) only has five or six digits of accuracy, it means that the
"correct" answer is about 1.225e-16, because "correct" is defined to mean
the sine of the double which is nearest to the actual value of pi.

It's nice to be accurate, but the claim that for large arguments the
computed value of sin is effectively "random" is pretty irrelevant, as the
same thing can be said of the "true" value of sin, when defined as "the
sine of the double closest to your desired x value" which is the closest we
could possibly come to a "true" sin.  If you're taking the sine of a large
number, your code is broken, and no sin function is going to fix it.
-- 
David Roundy
Department of Physics
Oregon State University