LATEX-L Archives

Mailing list for the LaTeX3 project


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 >>]

Print Reply
aparsloe <[log in to unmask]>
Reply To:
Mailing list for the LaTeX3 project <[log in to unmask]>
Tue, 27 May 2014 09:21:50 +1200
text/plain (59 lines)
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 <[log in to unmask]> 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.