Turns are Better than Radians (2022)

Yes and no. The x in e^ix is to SO(2) what Euler angles are to SO(3).

I’ve been writing code for 46 years. Not once have I had to code a derivative.

And for all the people who are concerned about how sin' 2πx = 2π cos 2πx, in actual code, it doesn’t matter. Let’s say that I’m writing a basic graphing function and I want to be able to display the slope of the sin curve at any point.

I am not going to expose the turn-based units to the user. Caring about slopes implies that I’m doing calculus and thus assuming radians. So even though my internal values are [0,1], I will label them as [0, 2π] (and the actual numeric values on the display may actually be something like [50,450] which is yet another numeric value we don’t display). So to get the slope at π/4, I’ll calculate cos_t 0.125 and display that value.

We do all kinds of unit translations in computing without worrying about it. This is just another case of that which observes that numerically speaking, using turns is better aligned with the underlying numerical algorithm for calculating trig values.

Having read over this entire conversation I feel that people are almost uniformly missing the practical impact of this, which is simply that you can write your own math in terms of "turns" as much as you like. Nothing stops you right now. Defining a sinT function that takes turns is trivial. And so on for all the functions.

I haven't done much graphics programming, but what I did I did with tau rather than pi. You all seem to be arguing about whether or not you need to enter some parallel universe where all the math is completely rewritten or something, but you don't. It was easy. It didn't clash with the universe at all. I just used "tau" instead of "2 * pi". That's, like, it. That's all there is to it. "const TAU = 2 * PI;" and I was done with the conversion work. Similarly, all that is being suggested is that instead of "sin(2 * pi * (1/4))" you define something like sinT and write "sinT(1/4)".

Seriously. That's it. You don't need to rewrite every math library in the world. You don't even need your math library to support it at all, these are not complicated wrappers. You don't need to redo the whole of calculus to worry about taking derivatives of it or whatever. Besides, degrees already has all the same problems and we use them a lot too anyhow. Having trig function variants that take degrees isn't that uncommon, this is just another variant. You don't need to go in to your math library and remove everything that isn't based on turns. You don't need to force it in the face of the user of your code.

It's true that the benefits of this approach are modest but the costs are way, way less than a lot of the posts seem to be arguing about. The costs are a few local function definitions and a new possible unit for the programmer to have to think about. How expensive that is depends on the local programming language and whether or not you can press the type system into service to represent units in a sane way, and even that is not a problem created by this proposal because I'd want radians and degrees isolated in the same way already.

If you are programming in a language or environment that has no (practical) way to encode the units into the type system, and you had a program that settled on "every angle is radians" I don't think I'd introduce this into my code base. But if you have something where you can very easily integrate it with the existing code and get very solid guarantees that my new "turns" unit is compile-time guaranteed to never mix with "radians" or "degrees" I'd definitely consider it.

> I’ve been writing code for 46 years. Not once have I had to code a derivative.

Haha !

I have been coding for much shorter time but having done some ML on orientations and on spheres in my time, I have had to take their derivatives all the time.

It will be interesting to consider folks who do machine learning on robot trajectories or analysing dynamics of robotic arms.