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 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 don't have a super-wide gamut of experience here and numerical analysis isn't my specialty, but nearly all trig implementations I've looked into (in both software and hardware) make heavy use of lookup tables and other shortcuts. I've never seen a Taylor series used in a general implementation - not saying it doesn't exist anywhere, but in most cases that I'm familiar with you could support turns just as easily with a different lookup table.
If you're being technical, it's usually not a Taylor series, it's a minimax series. (The difference is that Taylor series minimize error at a given value, whereas minimax is trying to minimize maximum error in a range).
Of course, if you're not using a standard math library implementation, you're probably preferring speed over accuracy, and so you might use a lookup table and linear interpolation to get a very coarse approximation instead.
Our favorite WebAssembly is an example! It specifically excludes trigonometry from the spec, because real hardware doesn't produce exactly the same results.
So mathematical libraries in WASM reimplement the trigonometric functions using series.
I've used Taylor series in numerical optimization. A function we were implementing needed to be differentiable (for automatic differentiation), but its definition had a special case, so we used a couple terms of the Taylor series in the special case.
edit: Sorry, to clarify, this was a function involving trigonometry but not simply vanilla sine or cosine. However, angular values being represented in radians did help in the same way I described in the parent post.
I have used the Taylor series approximations to produce the LUT over a defined interval. This may be generated pre-complication or at startup with a defined precision depending on the destination signed type.
Tend to use radians because we're moving from written proofs or simulations into embedded code in such systems. The code needs to read and work the same as those.
Why are math libraries consistently treated as space hogs if you don't keep them as barebones as possible? I've had sinDeg/cosDeg overloads for a while and I don't see why they can't be built into the base library; the same would go for a sinT/cosT that takes turns instead of radians or degrees. Why do we have to pick one and meticulously avoid having multiple?
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.:
If you've committed to representing all trigonometry in "turn" units, then you instead need to use: 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 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.