# Can I find sines or cosines of rational parts of π without using radians? If not, how do I reduce the errors caused solely by the transcendence of π?

this may be irrelevant for people who need fast code. But for me it's just the opposite -- i.e. in the specific situations when I know that the extra time allows me to make my calculations more accurate, I'm willing to wait for 5 minutes to modify a 1-minute sound file (I'm not joking). My question has two parts.

1. Conventional implementations of sine or cosine functions expect the argument to be in radians. This has one serious drawback. π is transcendental. Therefore, even if I wanted to reduce the range of my argument to something like (-π,+π], the problem would still be the same. If I choose to output all my data as IEEE doubles, it would be awesome if the error were small enough to be actually unmeasurable with IEEE doubles. However, this requirement can probably never be met for one simple reason. Dividing π/3 by π/9 is equal to 3. But dividing the nearest IEEE Double approximation of π/3 by the nearest IEEE Double approximation of π/9 is NOT equal to 3. So if the particular algorithm requires the argument to be in radians and if I don't know how exactly it works, then I can hardly subtract 2×π and think that the sine or cosine will come out the same as if I didn't (but it's supposed to).

2. Specifically for finding sines or cosines of rational parts of π, one might think that Chebyshev polynomials should make it possible to find these without involving radians altogether. However, let's say I ask the following question: "What's 2×sin(π/9) equal to?" The equation in question goes like this: 3×x - x^3 = sqrt(3) When I start solving this, I eventually discover that I'm supposed to take cube roots of complex numbers, even though the result is a real number. Many root extraction algorithms are designed for finding cube roots of real numbers, not of complex numbers. If I were to convert my number to polar form, divide the argument by 3 and convert that back again, I would be introducing even more errors into this. And I would be running into the exact same issue that I described in part 1. Honestly, I would suggest an entirely different approach to this, without involving the conversion to polar form. The algorithm would have to be designed specifically for finding the solutions of Chebyshev polynomials; as that's where the multiple-angle formulas come from. Sadly, I know about no more than one person who has described a similar approach in great detail and I'm not sure if anyone else has. If someone's interested, I can post the link to the relevant paper. So my question is: What approach[es] would you suggest me to take if I only care about accuracy and don't care about the time taken? I mean, as I've said, I don't need to store the final data with an accuracy of some 100 decimal digits, but IEEE doubles would be enough. Thanks a lot in advance.

• How does the transcendence of $\pi$ play a specific role here? Dividing $\frac{11}{3}$ by $\frac{11}{9}$ is equal to 3. But dividing the nearest IEEE Double approximation of $\frac{11}{3}$ (0x1.d555555555555p+1) by the nearest IEEE Double approximation of $\frac{11}{9}$ (0x1.38e38e38e38e4p+0) is NOT equal to 3 (0x1.7ffffffffffffp+1 $\approx$ 2.9999999999999996e+0). Commented Aug 2, 2023 at 20:24
• You could use the series expansion of sin/cos, substitute as you wish, and then calculate the expansion with a higher preciscion data type until your beyond the range representable by ieee double. Since the main contributor of the error will be in the first expansion terms you should be on the safe side. Commented Aug 3, 2023 at 6:26
• Could an alternative but similar situation be: Image to want to implement functions in multi-precision arithmetic. What help would or could the double precision values of sine and cosine be to simplify and shorten the computation of their multi-precision values? // Could you give an estimate when the standard math lib functions fail your purpose? For instance a one hour sine signal with an audible frequency takes arguments up to 10 kHz * 4000 sec = 4e7, which might reduce a double sampling step-size and result to 8 valid decimals (in a pessimistic interpretation). That does not seem too bad. Commented Aug 3, 2023 at 10:32
• Yes, I can give an example but here I'm told that my original comment was too long to be posted. Commented Aug 3, 2023 at 13:28
• @5-limit_JI : Ideally, you should write no comments that are not notifications on what you changed or added in the question text. The comment that such a notification reacts to might not be completely clear or appropriate, that might start a short discussion in the comments. But if you feel that you have to write long comments, then in most cases it would be better to edit the question. Commented Aug 4, 2023 at 12:29

The standard libraries of most programming languages have a function cospi that computes $$x \mapsto \cos(\pi x)$$. Would that solve your problem?

Otherwise I am afraid you need a computer algebra system, or at least a rational type, if you want to compute these cosines without error.

• Well, it depends very much on how the function would be implemented. If it were just a substitute for ordinary cosine where the argument would be multiplied internally by π, then there wouldn't be any point in doing this. But if it were something else, then yes, it would solve my problem to some extent. Even though not entirely, still a large part of my issue would probably be gone. So thanks for letting me know. I didn't know about that. Commented Aug 2, 2023 at 17:43
• No, it's implemented differently: sin(2*pi) returns -2.4493e-16; sinpi(2) returns 0.0. Commented Aug 2, 2023 at 20:58
• But I think it's worth pointing out that -2.4493e-16 and 0.0 are equal, to within floating point accuracy. That's perhaps not easy to understand when the argument is x=2, but if you had tried $x=1.5$, then sin(pi*x) and sinpi(x) would both result in approximations, and neither is exact -- but both are within some error bound of the exact answer. Commented Aug 4, 2023 at 10:53
• @WolfgangBangerth sinpi(1.5) and sin(pi*1.5) both return the exact result, -1. Maybe you meant $x = 2/3$? Commented Aug 4, 2023 at 16:09
• @FedericoPoloni Ah, bad luck -- I meant "any randomly chosen $x$". I picked a poor random choice. Commented Aug 5, 2023 at 8:29

Nothing you ever compute on computers is exact. As has been pointed out in a comment, it isn't about transcendental numbers: $$(11/9)/(11/3)=3$$ in exact arithmetic, but not in floating point arithmetic. However, in floating point arithmetic, you will get a result $$3+\varepsilon$$ that is accurate to within the accumulated round-off of all operations, which in this case will likely mean $$|\varepsilon|<6\cdot 10^{-16}$$. Very few things in life depend on knowing the answer to more accuracy than that, and I imagine your situation doesn't either.

But there are more problems. Sine and cosine aren't functions you can evaluate exactly. It is perhaps true that for some arguments, you can show that for example $$\sin(x)=1/\sqrt{3}$$, but $$1/\sqrt{3}$$ is not representable exactly in floating point either. Finally, sine and cosine are defined as infinite sums. Computers generally have a hard time evaluating infinite sums in finite time, even if you're willing to wait for a minute or three -- the best you can do is approximate these functions.

In other words, every step of what you're trying to do is based on approximations. That's just how it goes on computers. But because we generally don't care about the sixteenth digits of results. that's also ok.

• @njuffa Of course we care about correctness. But we generally don't care about the 16th digit of correctly (in floating point accuracy) computed numbers, and that's what the original question is about. Commented Aug 16, 2023 at 22:27
• @njuffa But thank you for the links -- this was an entertaining read. One can only applaud these authors for figuring this out, what a task! Commented Aug 16, 2023 at 22:28