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

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).

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.

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

sorry for stepping into an old thread, imho it should be allowed if it - the thread - spreads wrong wisdom …

there are! weaknesses in the calculation of trigonometric functions by calc,
imho more than neccessary, as:

  • other systems simply use lookup tables for calculations which are difficult in some ranges, too difficult for calc?
  • sin(pi()/2), cos(pi()/2), sin(pi()), cos(pi()) and similar are well known,
  • the [derivative/deduction/drain (what do you say in english for the german word ‘Ableitung’ reg. differential calculus)] of these functions around those special points is well known, it’s e.g. -1 for cos(pi()/2), 1 for sin(0*pi()), 0 for sin(pi()/2) and so on,
  • from knowing that i can calculate e.g. cos(pi()/2 -/+ ‘some_small_value’) to +/- ‘some_small_value’ without needing gigaflops in a 8-core high tech cpu, too difficult for calc?
    … continued …

… continued …

  • from '=rawsubtract(sin(pi()/2+x);1) ‘jumping’ from ‘0’ for small values of ‘x’ to 1,11022…E-16 at x=1,1E-8 one can see that the calculation doesn’t use the full power of ‘doubles’ (there are likely smaller differences between 1 and sin() for values between pi()/2-/+1,1E-8 which calc could show as doubles reach down to much smaller values (something like 2.2250738585072014E-308)),

imho the following statements in the answers and discussion are wrong:
‘No, this is normal,’ - it’s not normal, it’s simply wrong,
(‘and likely will not be changed.’ - never say never, but needs the ‘will’ to improve),
‘here and here and here’ - refer to fp-math difficulties in general, they don’t explain the inaccuracies in calc’s actual trig calculations which are ‘too big’,
‘Any software will therefore calculate the cosine or sine of an approximation of pi or pi/2’ - never say ‘any’,
… continued …

… continued …
‘Any software will therefore calculate the cosine or sine of an approximation of pi or pi/2’ - never say ‘any’, imho there are packages calculating in other ways, already calc uses a better approximation to pi() than 15 decimal digits, and any software is allowed to use ‘symbolic values’ or lookup tables,
‘Formula: from SIN(PI()/2 - 0.000000037) to SIN(PI()/2 + 0.000000037) all return result of 1.00000000000000000000’ - no, the result is different starting at -/+ 1,1E-8, it’s calc not showing! you the real value due to it’s f.cking b.llsh.t user trapping display rounding (check with rawsubtract), but being 1 in that smaller range is wrong anyway,
‘Wrapping the functions with ROUND(), rounding to the maximum precision ROUND(SIN();15) seems to get good results.’ - looks making things worse - as expectional - at least in 7.2dev under debian,
… continued …

… continued …
‘There is no way to fix it, because LibreOffice does not make symbolic calculations.’ - there is one very simple way, introduce symbolic calculations, ‘pi()’ is a step in that direction, and there should be multiple ways to fix the ‘too big deviations’ in calc,

am me and PIHunter right in the suspection that at least some of the trig functions are calculated with ‘less than double’ precision in any step?
… end … (for the moment)

bad news: sorry, '- from '=rawsubtract(sin(pi()/2+x);1) ‘jumping’ from ‘0’ for small values of ‘x’ to 1,11022…E-16 at x=1,1E-8 one can see that the calculation doesn’t use the full power of ‘doubles’ ’ was wrong, even if you calculate finer values for sin the smallest info doubles can store in a ‘1’ besides that ‘1’ is something like 1,11 e-16 …
good news: wikipedia has a nice simple taylor algo which calculates cos(pi()/2 correctly to 0, - link to wikipedia, click to open - , will propose that in a ‘bug’ …

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).

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.

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 is not the correct place for such things. You have my apologies. Still, I was hoping it might catch their eye.

If it’s a concern about the power series hit, possibly also provide additional functions SINPREC(), COSPREC(), etc etc

Global scale positioning calculation accuracy is impaired here. Not a common use of your average spreadsheet I guess. But that’s the only reason I ever notice these things in the first place. I can’t for the life of me believe I’m the only one, even if the group is small. :slight_smile: I may write an extension for this (but it will be a kludge for most everyone - refer back to tables and slide rule might be faster), or perhaps one has already been done… the point however: Native support is always preferable for common functions that serve interdisciplinary concerns.

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.

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

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!

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

Indeed :slight_smile: 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.