On Sun, May 29, 2022 at 11:14:02AM +0200, newbie nullzwei via gnumeric-list
wrote:
> the result of sin(x) for x = pi() in gnumeric is 1.2246467991473532E-16,
> and thus somewhat off from the correct value '0'.
That is incorrect.
sin(π) = 0 but pi != π, it is (approximately) 3.141592653589793... and
sin(pi) != 0.
To 50 decimal places, pi =
3.14159265358979311599796346854418516159057617187500
which is different from π to 50 decimal places:
3.14159265358979323846264338327950288419716939937511
and sin(pi) is mathematically equal to sin(π - c), where c is the
difference between the two: c = π - pi is (approximately):
1.224646799147353177226065932E-16
So when you calculate sin(pi), you are calculating not sin(π) but
sin(pi) = sin(π - c) = sin(c).
And sin(1.224646799147353177226065932E-16) = 1.2246467991473532E-16
Which is exactly the number that Gnumeric computes. Gnumeric is correct.
It also matches what Excel and LibreOffice return, although LibreOffice
(and I think Excel?) drop the last decimal place, for reasons best known
to Microsoft.
So Gnumeric is correct, and having sin(pi()) return 0 would be wrong.
> If you use sin(mod(x,pi())) for the absolute value, you get the correct
> zero,
That's because mod(pi(), pi()) = 0, so you are calculating sin(0).
If you use sin(mod(2.9, 2.9)) you get 0 too, but that doesn't mean that
sin(2.9) should give 0.
[...]
> my general POV: we need results that match the mathematical correct result
It is not mathematically correct to have sin(3.141592653589793) = 0.
There's no point in using extended precision 64-bit doubles if you are
then going to round the results to give *less* precision.
--
Steve
_______________________________________________
gnumeric-list mailing list
gnumeric-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnumeric-list
