MIME-version: 1.0
Content-type: text/plain; charset=UTF-8; format=flowed
Content-transfer-encoding: 7bit
References: <5382FD21.6040600@clear.net.nz>
            <CANQYN6zOq8dd5BUi32nCJGh9QgagZaaoj4UW1Ku3B4XWHi2PNA@mail.gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101
            Thunderbird/24.5.0
Message-ID:  <5383B06E.1000908@clear.net.nz>
Date:         Tue, 27 May 2014 09:21:50 +1200
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: aparsloe <aparsloe@CLEAR.NET.NZ>
Subject: Re: l3fp and sin(pi), cos(pi/2)
To: LATEX-L@LISTSERV.UNI-HEIDELBERG.DE
In-Reply-To:  <CANQYN6zOq8dd5BUi32nCJGh9QgagZaaoj4UW1Ku3B4XWHi2PNA@mail.gmail.com>
Precedence: list
Envelope-To: <rainer.schoepf@GMX.NET>
Status: R

On 27/05/2014 5:41 a.m., Bruno Le Floch wrote:
> 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.
Not at all: thank you for the full explanation.

Andrew