alt Hacker NewsTurns are Better than Radians (2022)
Comments
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 + ...
cos(2 pi t) = 1 - (2 pi t)^2/2 + ...
sin(2 pi t) = (2 pi t) - (2 pi t)^3/6 + ...
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 are interfaces that provide both versions, and since as the article points out there are cases where the turn-based versions can be more efficient, that's probably the right way to go.
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.
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.
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.
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.
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.
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.
> But math never decreed that sine and cosine have to take radian arguments!
If you don't use radians you have to add to add conversion factors everywhere to do calculus. Radians are the natural unit for sin/cos just as E is the natural base of the logarithm and exponential functions.
The Fortran 2023 Standard introduces new intrinsics:
"The intrinsic functions ACOSPI, ASINPI, ATANPI, ATAN2PI, COSPI, SINPI, and TANPI are trigonometric functions in which angles are specified in halfrevolutions (that is, as multiples of π)."
Yes, the idea of a turn [1] is interesting. And maybe useful.
I have a different question: What would it take for a compiler to remove (elide) the multiply by pi + divide by pi that the author uses as an example? I guess one would not have to go as far as a Lean proof that two bits of code produce the same result?
The problem with this is that when I see pi I know we're talking about an angle; when you use turns it's just some number. Maybe in typed languages it would work better.
This seems to be mostly from the perspective of what makes the most sense to use at an API boundary.
Rather than trying to agree on the best meaning the various integers or floats that we're passing around, maybe we should instead build a more complex angle type that doesn't force callers to conform. Like, I can pass minutes or seconds to functions that accept a time type and it just works because they're not being collapsed to numbers. Is there any reason we couldn't do that with angles too?
One weird unit for angles is the mil, defined as 6400 mils in a circle. This unit is very useful for artillery, since 1 meter displacement at a distance of 1 km is 1 mil [†]. Thus, you can see how much you missed by, divide by the distance, and easily determine how much you need to adjust your aim in mils. Another interesting thing about artillery is they traditionally do a binary search to get the distance correct, which they call "bracketing". Link: https://unitedtaskforce.net/training/sop/communication/artil...
[†] Note that this isn't exactly correct since it corresponds to pi = 3.2. A mil is almost the same as a milliradian, but 6400 mils in a circle is much more convenient than 6283.18... milliradians in a circle.
And could use fixed-point decimal for more efficiency since can store as integers and use integer hardware for them. So for instance with 32-bits, the 16 most-sig bits store the number of turns and the 16 least-significant bits store the fraction of a turn. Then if you want to wrap angles that exceed 360 degrees back around the circle, you can simply Logical_AND with 0x0000FFFF. And while you are at it, you could just use fixed-point decimal for sine and cos, whereby the maximum of +1 or -1 map to the most positive and most negative integer value. These type of optimizations were common before FPUs were cheap and fast.
This can be useful for some geometry, but pi isn't a completely arbitrary choice and some useful relationships are lost when not using radians.
I use different angle units depending on the application. On a platform with 8-bit index registers, 1/256 of a turn can be useful. IIRC Pico-8 uses turns.
> It turns out (pun intended!)
Thanks, I was waiting for this pun the moment turns were introduced in the article.
This alone should be a reason to drop the pi factor: it's basically impossible to get an exact zero for the sine of a half-turn:
sin(1*pi) = 1.2246e-16
Dumb question: For multiplying for smaller turns such as 1 arc-second (1,296,000 in 1 turn), that would floating point precision issues be a tiny slight issue (22619.4671 arc-seconds in 2pi radians), or is it just a coding convention change?
The floating point expressions needed to represent the math library functions with decent precision and performance becomes significantly more weird and complex with turns.
Please stick to radians.
Even better : did you know (-1)^x draws the unit circle in the complex plane ? No need for complex exp and i*pi
In the old days of making 8 bit video games we used BRADs of 0-255 - worked well and the wrap was easy.
Are there any c/c++ libs / headers that use this (without converting to radians in the background). I like this idea.
Fails to mention that radians relates angle to arc length.
I think the author is either being disingenuous or doesn’t understand the subject if they don’t honestly address the reason radians are used in the first place. I’m leaning towards the latter, because I can’t imagine someone having an ulterior motive for pushing for trig reform like this, lol. Radians really are the natural unit for trigonometry. With that said, I certainly agree that a lot of code would be simplified by using turns over radians, especially outside the context of numerical methods. I could see myself supporting the addition of sint(x) and cost(x) functions to the math standard library, where sint = “sine turns”.
While not a strict rule, Chesterton’s fence is a good heuristic: before we change something, we should first attempt to understand why it is the way it is.
I was hoping for some code examples but got none. Can anyone help?
Indeed, this is what Pico-8 uses for its trigonometric functions[1] (angles go from 0 to 1, instead of from 0 to 2*Pi). I was surprised by this at first, but then I found it is very convenient and simplifies a bunch of stuff.
> There are many implementations of sin, but no matter which one you look at…
I’ve had a brief moment of hope, forgetting the point was about mathematics.
Here's another good reason to think in turns: it turns Euler's formula from this Eldritch Terror:
e^(i*x) = cos(x) + i*sin(x)
-1^(2x) = cost(x) + i*sint(x)
I'm not super versed on the subject, but I think there's a case where using radians allows you to do direct multiplication without any conversion when trig isn't even involved, for rotation or transformation matrices? In which case this would fall apart rather completely if that doesn't work anymore and wouldn't be any different than switching to degrees, a convenience fix that requires conversion anyway.
Wait until you discover gradians: centesimal system applied to angles. A turn is 400 gradians, right angles are 100 gradians.
Same advantages as here but multiplied times 400...
I think it misses the whole point of Pi. Turns are for angles. Pi is not a measure of angle. It is a number that can be used to find the length of an arc. For example, it gives half-length of an arc, given an angle in Turns. So it deals with lengths, not strictly angles. Turns deal with angles only.
It's similar to why taxicab distance is better for distance measurement on limited hardware where sqrt() costs precious cycles. The reason to use sin() though is because it's a lookup table (where it counts) and not a bit of math, so moving to turns isn't necessarily a win.
At least we got metric units out of the French Revolution.
Gradians exist because "let's change everything, even things that aren't broken".
The title should say (2022)
Norman Wildberger has an alternative system for trigonomtry:
Understanding uniform motion: are radians really necessary? | WildTrig
https://youtu.be/CnQXRdgN_7I?si=EiYY99i6mBOIyczI
Wild Trig: An introduction to Rational Trigonometry
https://youtube.com/playlist?list=PLIljB45xT85CyF_7bKd6y36VA...
Turn is a measurement unit, and measurement units are just numbers. So turn ≈ 6.28318530718. You're welcome.
That should put to bed that whole τ crap. "But the symbol τ is used for other things!" Yeah, yeah, yeah, just write turn. Even better, because it's more international and has more precedent, write rev for revolution.
The math is definitely not fine with turns, because your Euler formula e^ix = cos x + i sin x no longer holds. We can use a base other than e, namely B = e^2pi which around 535.4916. This doesn't have the nice e properties like d/dx e^x = e^x.
The elegant fact that the base of the natural logarithm, which produces an exponential function that is its own derivative, also shows up as the basis for the above Euler's formula, shows that radians are special: like what binary is to computers.
The natural logarithm being its own derivative is in fact directly linked to the derivative a radians-based sin(x) being cos(x) and so on. Make it any other unit, and you have a mess of conversion factors worse than 2pi.
Imagine complex chained derivatives, double and triple derivative, chain and product rules, all stuffed with trig functions and generating gratuitous piles of cascaded conversion constrants because radians were not used.