MIME-Version: 1.0
References: <5382FD21.6040600@clear.net.nz>
Content-Type: text/plain; charset=UTF-8
Message-ID:  <CANQYN6zOq8dd5BUi32nCJGh9QgagZaaoj4UW1Ku3B4XWHi2PNA@mail.gmail.com>
Date:         Mon, 26 May 2014 13:41:16 -0400
Reply-To: Mailing list for the LaTeX3 project
              <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
Sender: Mailing list for the LaTeX3 project <LATEX-L@LISTSERV.UNI-HEIDELBERG.DE>
From: Bruno Le Floch <blflatex@GMAIL.COM>
Subject: Re: l3fp and sin(pi), cos(pi/2)
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <5382FD21.6040600@clear.net.nz>
Precedence: list
Envelope-To: <rainer.schoepf@GMX.NET>
Status: R

Hello,

Short answer: use the trigonometric functions which expect arguments
in degrees: sind, cosd, tand,...  sind(180) correctly gives -0.

On 5/26/14, aparsloe <aparsloe@clear.net.nz> wrote:
> \fp_eval:n { sin(pi)  } -> 0.0000000000000002384626433832795
>
> as if the 16 nonzero digits after the run of zeros are the significant
> ones.

They are.  When computing sin(pi), the great majority (exceptions:
sage, mathematica, maple,...) of programming languages/libraries will
first round pi to a number that can be represented in memory (with a
finite number of binary or decimal digits), then compute the sine of
that number, then round again.  For instance, python:

    echo 'from math import *; print sin(pi)' | python

gives 1.22460635382e-16, which is the representable number (in a 53?
bit mantissa) closest to the exact sine of the representable number
(in a 53? bit mantissa) closest to pi.  Exactly the same happens in
l3fp, as it should.  pi is rounded to 3.141592653589793, and the sine
of this number is computed, giving approximately 2e-16 as you saw.

In an earlier version of l3fp, I had actually implemented
trigonometric functions so that they would have a period of exactly
3.141592653589794 (there were technical reasons for this approximation
of pi instead of the slightly more accurate 3.141592653589793).  Now
that trigonometric functions are available in degrees too, it is not
necessary to cheat for radians any more.

> Rounding the cosine to 16 figures gives a 6 in the last place, which
> seems large to me.

cos(pi/2)
=> cos(3.141592653589793/2)
=> cos(1.570796326794896)
=> 6.192313216916398e-16

The approximation of pi differs from the real value by about 2e-16.
When dividing by 2, the last digit is odd hence there is a rounding
involved (as per the IEEE standard the rounding should be in such a
way that the result's last digit is even), giving an approximation of
pi/2 which is off by about 5e-16+(2e-16)/2=6e-16.  Since
cos(pi/2+epsilon) is approximately -epsilon, we do expect the result
of cos(pi/2), computed with 16 decimal digits of precision, to be
about 6e-16.

> Perhaps sin and cos and their fellows should be given
> the exact value 0  at the appropriate multiples of pi/2?

No.  See above: use sind, cosd, and so on.

Regards,
Bruno
PS: Probably more details than needed, sorry.