Turns Are Better Than Radians: Why Your Code Multiplies by Pi for No Reason

I think I cautiously agree with this notion to some extent, but IMHO the real answer is that it's application-dependent, and if you're writing a low-level trig library and you have to pick one or the other, it really isn't clear to me that turns should win over radians.

I expect many systems that use trigonometry would sometimes use small-angle approximations either for efficiency or to bootstrap to the general case. It'd be natural to use Taylor series here, i.e.:

cos(x) = 1 - x^2/2 + ...

sin(x) = x - x^3/6 + ...

If you've committed to representing all trigonometry in "turn" units, then you instead need to use:

cos(2 pi t) = 1 - (2 pi t)^2/2 + ...

sin(2 pi t) = (2 pi t) - (2 pi t)^3/6 + ...

In this case it would be less accurate and efficient to force everything into turns if you ever need to work with radians.

Closely related to this, if you ever need the derivative of a function that does trig (e.g., in numerical optimization), you may as well use radians because if you don't, any extra factors you apply will appear in the expressions for the derivatives and you'll have to deal with them there anyway.

Basically for that reason, it's pretty clear that trigonometry in terms of radians is the "correct" convention mathematically speaking (away from computers), since derivatives of the radian-based trig functions are so easy to express. Given that, if we have to pick one convention...isn't it less confusing to use the same thing everywhere? That said, there ar […]

I like to store angles as turns in my own code, because (as noted) it makes quarter-turns computable without rounding. OTOH if you need, say, twelfths of a turn, you might want to just store angles as degrees since that’s already common.

Michael Spivak, in Calculus (3rd ed p. 301) considers the unit choice to be a property of the function and initially defines sin° and sinʳ (before settling on sin meaning sinʳ) and considers “sin x°” and “sin x radians” to be misleading, saying that ‘a number x is simply a number—it does not carry a banner indicating that it is “in degrees” or “in radians”’. I don’t really understand this argument, since in science and engineering we constantly carry units around with our quantities.

Very bold title! Turns are very convenient until you need to calculate a rate of change, as of course d/dx sin(2pi x) = 2pi cos(2pi x). Unfortunately this is a common enough problem that I will be sticking with the radian.

The problem is that trigonometric functions are used in many more fields beyond geometry. The input is not always an angle around a point in euclidean space, it could be phase angle of a periodic signal. You can make an alternative set of trig functions that take turns, but you will anger a lot of people if you mess with the vanilla trig functions.

Well, \tau vs \pi is a question of taste, but 1 vs. \tau (or \pi) is not. Because you don't get rid of these weird constants, because \pi (or \tau) is, as a fact, in the circumference and area of circles and in surface and volume of spheres, and in other places. There jus is a weird constant.

And for APIs, you could reasonably well have turns or radians or degrees or even percentage of turns, whatever -- it depend on the context what is 'better'. What's really missing, I think, is the support of units in programming languages (in the type system) so that you cannot mess up when invoking sin()/cos(), because you would be forced to provide a unit.

Rather than sin(), cos() and motion on a circle it is fun to consider uniform speed motion along the perimeter of a regular polygon and its projection hor() and ver() along horizontal and vertical directions.

You can parameterized the motion in terms of the time T to complete one period and consider it's horizontal (or vertical) shadow at any t mod T.

This is related to DFT. As one increases the number of vertices of the regular polygon we will recover sin and cos in the limit. 2 \pi will show up in the ratio of the distance covered in one period of the uniform speed motion and the extents of the projected motion.

Another interesting (and fundamental) construction is to forget about circles and polygons entirely. Simply consider a periodic function over a bounded length L. Consider first the discrete case where the domain is divided into k parts. We want to find an orthonormal basis for all nicely behaved (smooth) periodic functions on this domain.

But there are infinitely many orthonormal basis sets for periodic functions on this domain. We are free to choose any. One choice is that adjacent values do not have large adjacent differences. This can be measured by squared adjacent differences. We choose that basis set that minimizes this quantity.

For the discrete case we recover DFT basis and taking limits carefully we end up with sinusoids.

\Pi will show up because of the requirement of orthonormality.

I argued this idea to a couple of my classmates when I was a physics undergrad, and they agreed. However, I later changed opinions because of what this does to the derivatives/integrals of your trig functions.

For general periodic functions, [0, 1) is a good domain. But circles and spheres are geometric objects, and radians/steradians are geometrically significant units that are well suited for general purposes.

I do remember that Doom uses an interesting alternative representation where an angle is a u16 multiple of `(2 * pi) / 65536`. Fixed point is sometimes a good choice in games and simulations due to having uniform precision.