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.22460635382e16, 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 2e16 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.192313216916398e16
>
> The approximation of pi differs from the real value by about 2e16.
> 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 5e16+(2e16)/2=6e16. 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 6e16.
>
>> 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
