Re: Re: no tests for trigonometric functions? need help / hints how to adapt tests for gnumeric 'long' version,



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]