## LATEX-L@LISTSERV.UNI-HEIDELBERG.DE

 Options: Use Forum View Use Monospaced Font Show Text Part by Default Show All Mail Headers Message: [<< First] [< Prev] [Next >] [Last >>] Topic: [<< First] [< Prev] [Next >] [Last >>] Author: [<< First] [< Prev] [Next >] [Last >>]

```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.
>
>> \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