Ask Your Question

Re: Calc - COS(), can this be fixed?

asked 2017-08-24 09:38:10 +0100

PiHunter_LM gravatar image

It is readily apparent that the COS() function is inaccurate (check COS(PI()/2).

I do not know if this is a system call, or an internal math library. Either way it can be fairly unhelpful for precision calculations. Also, SIN() on larger angles is not accurately handled (check: SIN(PI()) should return 0, it does not).

A work-around is to instead: 1) if angle > pi/2 then reduce it to QI and deal with sign issues separately 2) if COS(angle) is desired, call SIN(PI()/2 - angle) instead

Can the trig function accuracy be improved? Or, failing that, is there any hope of incorporating this into the program itself so that the function error is more transparent to the end-user? Any factor of pi/2 should be correct regardless of other floating point errors. (Many other functions you may care to perform rely upon factors of PI/2 cancelling out variables in those locations).

edit retag flag offensive close merge delete

5 Answers

Sort by » oldest newest most voted

answered 2017-08-24 10:15:23 +0100

No, this is normal, and likely will not be changed. Any person doing floating-point maths using computers should be prepared to such stuff.

See here, and here, and here for some information on this.

edit flag offensive delete link more


I have read this over before... oddly it means a great deal more now. I must have learned something along the way. ;) Thanks for the redirects! The others were also quite edifying!!

PiHunter_LM gravatar imagePiHunter_LM ( 2017-08-25 17:53:52 +0100 )edit

answered 2017-08-24 22:22:13 +0100

floris v gravatar image

The nonzero answer is cooct. The number pi is irrational, that means that it cannot be represented in any number system. Any software will therefore calculate the cosine or sine of an approximation of pi or pi/2. Still, many calculators do give result 0, maybe because they use less accuracy or have a better formula. Anyway, bugs should not be reported here.

edit flag offensive delete link more

answered 2017-08-25 11:47:46 +0100

PiHunter_LM gravatar image

updated 2017-08-25 18:04:28 +0100

As for nonzero being correct, please refer back to sine of any angle = length of side opposite from the angle/length of the hypotenuse, cosine any angle = length of the side adjacent to the angle/length of the hypotenuse... These are the most basic definitions of these functions before any numbers get thrown in the mix. Good luck convincing anyone that zero divided by any number is anything other than zero or that any number divided by itself, is any other result than 1. The value of the "any number" whether symbolically implied or explicitly stated is irrelevant unless "any number" actually is 0, exactly.

You don't need 12 (or more) different power series expansions to accomplish trig functions. If you understand what the code names represent (sin(), cos()... et al) you know that any can be determined from the most accurate calculation of any two (one the inverse function of the other) power series expansion for angular values 0-pi/2 and a bit of mathematical shuffling to adjust for trig identity properties, identity reflection and quadrant locality of the input angle (that has been reduced to it's equivalent value below 2pi). This may be quite edifying if you really want a better explanation and more information.

Which led me to pointing out the SIN(PI()) problem, since the accuracy of the used expansion seemed adequate for display limitations at least up to sin(PI()/2), but not necessarily beyond that... Why? Because it means the value of PI() in this issue is not the relevant concern. You can easily see that PI() is accurate as a double. This means the accuracy of the trig functions only has single precision. You can correct the issue one of three ways. 1) Rewrite all the power series code to have double precision. 2) Limit calculations back into a range where errors due to foreshortened accuracy at least behave properly at non-value related boundaries. 3) Do both. Regardless of actual decimal values involved: sin(pi/2) and cos(0) will always = 1; sin(0) and cos(pi/2) will always = 0; sin(pi/4) and cos(pi/4) will always = SQRT(2) / 2. If you determine the floating point values of the definitions, and then compare results of calculations against them you can always limit return results to the definition accuracy vs floating point accuracy and thereby not carry errors through in those places. For trigonometry the 0 and 1 are needful, the point of symmetry quite helpful, others would be merely convenient but not required (yes there are more). (They used to do all this with tables and 16" or so of slide rule, if you can believe that. Can you say "a nightmare of work" for very limited accuracy? Oh yeah, in the snow, uphill both ways. -.O )

Finally, it isn't a bug report per se, as it isn't technically a programmatic bug, it's a request for more accurate handling of trig functions. Perhaps, this also ... (more)

edit flag offensive delete link more


I agree with most of your points. As to improving the code, you need to talk to the developers, not to the users who hang out here. Your chances to be noticed by the developers here are minimal.

floris v gravatar imagefloris v ( 2017-08-25 12:20:45 +0100 )edit

Well, joy for the understanding, heavy sigh for trying to contact the devs directly. Thanks much =D

PiHunter_LM gravatar imagePiHunter_LM ( 2017-08-25 12:35:53 +0100 )edit

Heh, I stated something wrong anyway. I'll just share the formulas and result and you can choose to make sense of it ... or not. LOL

Formula: from SIN(PI()/2 - 0.000000037) to SIN(PI()/2 + 0.000000037) all return result of 1.00000000000000000000

Is the internal value of pi restricted to single in the functions or... what I said above? or something else I don't know about? Probably some combination that will make me feel foolish. Cheers!

PiHunter_LM gravatar imagePiHunter_LM ( 2017-08-25 13:04:35 +0100 )edit

answered 2017-08-25 18:59:21 +0100

m.a.riosv gravatar image

Wrapping the functions with ROUND(), rounding to the maximum precision ROUND(SIN();15) seems to get good results.

edit flag offensive delete link more


Indeed :) Thank you for that. Sadly, it has come to me after some experimentation in VB that the range of accuracy I am dabbling in exceeds 15 digits by some as yet unknown amount, I have to write some code to be able to test my formulas in that medium. I believe it's not more than 3 to 5 digits, but playing around right in that range with the limitations there explains many things. The last article Mike offered explained a few things about the hardware I was not aware of also... so, ah well.

PiHunter_LM gravatar imagePiHunter_LM ( 2017-08-25 22:59:07 +0100 )edit

answered 2017-08-24 10:20:40 +0100

Regina gravatar image

There is no way to fix it, because LibreOffice does not make symbolic calculations. If you need such, you should use a CAS (computer algebra system).

edit flag offensive delete link more
Login/Signup to Answer

Question Tools

1 follower


Asked: 2017-08-24 09:38:10 +0100

Seen: 195 times

Last updated: Aug 25 '17