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 π?

Question

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.

Answer 1

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.

Answer 2

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.