Turns are better than radians | Hacker News Reader

Turns are better than radians

computerenhance.com

699 pointstodsacerdoti471 comments

> But math never decreed that sine and cosine have to take radian arguments!

That is not entirely true. It comes from the relationship between those functions and the complex numbers via the Euler formula.

     ix
    e    = cos x   +   i sin x

There may be arithmetic/numerical inconveniences, but that's not all there is to "math".

Let's define ncos and nsin ("nice cos, nice sin") as follows:

   nsin x = sin 2πx
   ncos x = cos 2πx

So then what do we make of:

   ncos x   +   i nsin x

This has to be

   cos 2πx  +   i sin 2πx

which is then

     2πix        (   2π) ix        ix 
   e           = ( e   )      =  f 

      
           2π

Where f = e is a weird number like 535.4916. This f doesn't have nice properties. E.g.:

      d     x           x
      -   f     /=    f 
      dx

Otherwise it works; for instance 90 degrees is 0.25 and surely enough

     0.25i 
   f          = i

In situations not involving e in relation to angular representations via Euler, f cannot replace e.

I'm all for having parallel trig functions in libraries that work with turns, though.

The annoying 2π factor shows up in lots of places though. Should way, say, in electronics, redefine a new version of capacitive reactance which doesn't have 2πf in the denominator, but only f?

I see where you're coming from, if the formulas end up having weird numbers like 535.4916 or numbers like 2.718 or 6.28318 then obviously there's something suspicious about the equation. But small correction though. You got the number wrong, it's actually much more weird than any of those mentioned. The actual equation you come to for ncos an nsin is:

(-1)^(2x) = ncos(x) + i nsin(x)

And yes, -1 is a very weird number. If you take it to the power of something divisible by 2 you get itself raised to zero. What's up with this spooky periodicity? Also if you have x=1/4, then we get weird numbers like sqrt(-1) what on earth is that all about? No way that will fly, no way. No I'll take my 2.718^((-1)^(1/2)) and multiply through with 6.28318 that way I don't have to bother understanding what I'm doing I can sleep comfortable at night knowing that someone else has done all the thinking that needs to be done on the matter, and that turns or rotations are a blasphemous concept that breaks the very concept of math through scaling of an axis. You'd think math was strong enough to withstand such a minor change, but the textbooks do not mention it thus it must not be contemplated!

This is a very good point, but it took me a minute to get what you were saying beneath the snark. Translating without the snark:

There's a famous equation relating sin and cos to complex exponentiation. It also helps explain the Taylor expansions of sin and cos, which is one way to compute them and to find properties about them. It's a very important equation. It is:

     ix
    e    = cos x   +   i sin x

kazinator's point was that this equation relies on cos and sin taking radians as arguments. If they take turns instead, then you need to insert messy extra constants to state this equation!

jVinc's counter-point, made with lots of snark, is that there's an equation that's even nicer if you just instead measure angles in turns with ncos and nsin:

    (-1)^(2x) = ncos(x) + i nsin(x)

It's similar, but doesn't require the magic constant e.

A proof sketch that these are equivalent:

    (-1)^(2x) = e^ln((-1)^(2x)) = -e^(2x) = e^(i * (2 pi x)) using e^(pi i) = -1

Wow, this version makes intuitive sense when retroactively applying what I already know about the complex plane, and rotations about it. Thank you!

Perhaps an even nicer equation:

    1^x = ncos(x) + i nsin(x)

using a multi-valued definition of the exponentiation on the left hand side.

Isn’t this just changing units to suit your purpose?

Same way we might use electron volts rather than volts to make the equations nice.

Yes, it's exactly that. Changing the units from radians to turns, to make your equations nicer, because turns are evidently the more natural unit.

That's a nice result. If we rearrange the products in the exponent we get

     2πix          πi2x          (  πi ) 2x
   e         ->   e         ->   (e    )

Where e^(πi) is -1. That shows there is something to the turns units; we can express the analog of the Euler identity using exponentiation using a base and factor which are integers.

Huge selling point for turns, IMHO.

>Huge selling point for turns, IMHO.

Ok, then let’s measure angles in quarter-turns! Then the equation becomes even nicer:

i^x = cos(x) + isin(x)

Beautiful! :-0

Except not. Because you’re obscuring the connection of sin/cos with their hyperbolic counterparts. I.e. this is no longer true:

sinh(x) = -isin(ix)

cosh(x) = cos(ix)

Also, this new convention obscures the connection with the exponential map of Lie groups.

I.e. the exponential map of the complex unit circle as a Lie group is:

e^ix = cos(x) + isin(x)

Similarly, the exponential map of the unit hyperbola of the split-complex plane is:

e^jx = cosh(x) + jsinh(x)

Similarly, for the group of unit quaternions:

e^q = cos(|q|) + sin(|q|)(q/|q|)

These are deep connections, which would be obscured by using anything other than radians.

> Because you’re obscuring the connection of sin/cos with their hyperbolic counterparts.

Only because we forgot the name change: these are supposed to to be nsin and ncos.

Remember also that people use sin and cos with 360-degree degrees just fine; and don't worry about wrecking the connection to the hyperbolic counterparts --- and without changing the names, either.

That version of euler's formula might make a nice case for half turns. Then it's just

(-1)^x = ncos(x) + i nsin(x)

It's obvious how to handle it for integers (an even number of half turns is 1, an odd number is -1), and the extension to real numbers aids the intuition.

Or, depending on your focus, quarter turns are very clean too:

i^x = ncos(x) + i nsin(x)

Either way, turns > radians (it's what I think in when doing most fourier kinds of work anyways!).

>The actual equation you come to for ncos an nsin is:

>(-1)^(2x) = ncos(x) + i nsin(x)

Try to formally define this procedure, though. You end up going in circles.

Here's another version:

lim[N->infinity] (1 + ix/N)^N = cos(x) + i sin(x)

Now there are no "weird numbers", and both sides of the equation can be calculated directly, even by hand if you wanted.

If all you're teaching students is a bunch of formulas to be memorized, the (-1)^x notation is kind of cute. But usually when teaching math, we want to build some kind of understanding.

> Try to formally define this procedure, though. You end up going in circles.

The cos(x) + isin(x) formula gives us a way to find the point on the complex plane's unit circle corresponding to an angle x, given in radians. (Plus it does more, because the argument is complex valued.)

The new formula with ncos and nsin does the same thing for an angle given in turns. E.g 0.25 (90 degrees): -1^(0.5) = i. It's understandable in terms of roots of -1.

When you want to know the principal N-th root of number on the complex plane, you can simply divide its argument (i.e. angle) by N. The other roots are then equidistant points around the circle. So for instance, the square root of -1, which is sitting at 180 degrees, is found at 90 degrees, and is therefore i.

We can use -1 as the reference for measuring angles. The turns unit (one circle) is twice as far around the circle as as -1, so that's where we get the 2. Because 90 degrees in turns isn't 0.5, but 0.25.

We could use 1 directly, but then we need the first complex root of unity. For instance, here is the Wikimedia diagram of the fifth roots:

https://en.wikipedia.org/wiki/Root_of_unity#/media/File:One5...

That root which is close to i, has an angle which is exactly 1/5 turns. There is a relationship between turns and roots of unity, because N roots occupy N equidistanct points on the circle spaced by 1/N turns.

>It's understandable in terms of roots of -1.

You seem to have missed the point. You need the formula I gave to rigorously compute the roots of -1. Of course, you could notice that (cos(x) + i sin(x))^n = cos(nx) + i sin(nx), but that's what I meant by "going in circles". You end up defining (-1)^x in terms of sines and cosines, making the "formula" trivial. It's difficult, working this way, to understand why (-1)^(1/3) is (1 + isqrt(3))/2 and not just -1.

By contrast, the Bernoulli formula is actually computable. In fact, the CORDIC algorithm corresponds quite closely to computing the Bernoulli formula by repeated squaring. The use of arctan(2^(-n)) is just like taking (1 + i2^(-n))^(2^n).

There's a reason why math is structured the way it is.

> You end up defining (-1)^x in terms of sines and cosines

But we are explicitly doing that; we have "nsin" and "ncos" on the other side, and those are explicitly defined as just cos and sin with a scale factor applied to the argument.

The goal is simply, if there is a goal, can we have a nice correspondence between complex exponentiation of some base and the scaled sine and cosine that work with turns.

Hey look; if we change the angle coordinate so that a full circle is just 1 rather than an irrational number, then the transcendental e disappears from our version of this famous equation.

> if the formulas end up having weird numbers like 535.4916 or numbers like 2.718 or 6.28318 then obviously there's something suspicious about the equation.

Well, 2.718 is different than those numbers, because the derivative of 2.718^x is 2.178^x, which is a very interesting property of 2.718. The same cannot be said about 535.4. (6.283 is the ratio of a circle's, diameter to radius, which is just something intrinsic to the universe. I think it even transcends the universe, but that's hard for me to reason about. But basically, both 2*pi and e are fundamentally interesting.)

Circumference to radius.

But it really has nothing to do with the universe, except insofar as maths happen to (imperfectly) match it.

Presumably if the universe seemed to match some other maths, we would have invented that variety instead. The Greeks knew the Earth was round, yet made up plane geometry; and never touched on spherical geometry, as far as we know.

Astonishingly, the concept of the number line did not surface until 2000 years later. With the number line, school children can do on command what the best mathematicians of antiquity struggled with for centuries.

This makes a lot of sense when you are expecting to take derivatives, integrals, or use complex numbers.

In cases outside of that, radians lose their advantage over turns.

If you're not using derivatives, integrals, or complex numbers, maybe you'd be better off using Wildberger's "rational trigonometry" with quadrances and spreads instead of angles? I haven't actually tried it myself. Wildberger's motivation is a sort of ultra-strict Platonism* mixed with the desire to extend analytic geometry to fields other than the real numbers, though, so it wouldn't be surprising if it wasn't actually a simpler way to write Asteroids. Doing trigonometry in Galois fields sounds super cool though and I hope I understand it one day.

Alternatively you can just directly represent angles as unit vectors in the desired direction, which is pretty much the same as using complex numbers. Angle addition is complex multiplication, angle bisection is complex square root, and computing the sine and cosine is simplicity itself. (This takes twice as much space. If you choose to store only the real part of the complex number, you can only represent angles up to half a turn, same as in Wildberger's approach, you lose some precision near the limits, and the other operations require some extra computations.) I have tried this, for example in http://canonical.org/~kragen/sw/aspmisc/my-very-first-raytra... and https://gitlab.com/kragen/bubbleos/-/blob/master/yeso/sdf.lu..., and in the cases I've tried it, it works great.

I'm interested to hear other people's experiences on this count!

______

* His main concern is that irrational numbers don't, in some sense, really exist, so they're a bad basis for trigonometry. As I understand it, not only is Platonism now a minority among foundations-of-mathematics types, but even Platonists generally believe that irrational numbers are just as real as rational ones, so as I understand it, Wildberger's viewpoint is held by quite a small minority. That doesn't, of course, imply anything about whether it's correct.

I never saw rational trigonometry, but I imagine it is mathematically overkill in another sense. When calling `sin` or `cos` in code you get back a rational approximation to the presumably irrational answer.

From what I quickly gleamed, using spreads would be really annoying to represent rotations, because you lose 'aditivity'. Two subsequent rotations with spreads a and b do not have spread `a` and spread `b`. Lots of code using trig is about rotations, so losing that feature would probably not be the nicest.

In order to reason about the quality of the rational approximation, you need to reason about the irrational number it's an approximation to, for example as a Dedekind cut. Wildberger, rightly or wrongly, doesn't trust reasoning about that sort of thing; he wants to ground everything in the rationals. Maybe he's worried about finding some equivalent of Russell's barber paradox in the irrationals.

Also, of course, irrational numbers don't allow you to extend trigonometric theorems to Galois fields, complex numbers, and so on, which to my mind is a much more interesting direction. I don't know how much you lose if you use Wildberger's construction into a division algebra like the quaternions.

I don't actually know how you compute the "angle sum" in terms of Wildberger's spreads, but I'm pretty confident that there's a way to compute it, and it's pretty simple.

In the unit-vector representation I described, angle-sum is not just simple addition, but it's really not that bad: (a + bi)(c + di) = (ac - bd) + (ad + bc)i. That's four real multiplications, an addition, and a subtraction, and the result is exact if computed in bignums or bignum rationals. This is usually cheaper than computing sine and cosine, especially if you can use SIMD or vectors, and of course if you want to rotate some points around a center, you end up having to multiply by the sin and cos in exactly the same way anyway. (Maybe in strength-reduced fashion if you're texture-mapping or something, but that applies just as well to representing the angles as sin and cos.)

So if I wanted to, say, calculate the height of a pole from the length of its shadow, I should use Wildberger's rational trig, because I don't need derivatives, integrals, or complex numbers?

You can do that without derivatives, integrals, complex numbers, sines, cosines, tangents, exponentials, square roots, or even addition and subtraction. If the pole is plumb, erect a pole smaller than you with a plumb bob, measure its length a and its shadow's length b, and then calculate the height of the original pole from its shadow's length c as ac/b.

If you have a slide rule, you can do this in a single motion: align c on the C scale over b on D and read off the answer on C above a on the D scale.

Sure. No smiley face needed, unless geometry makes you smile.

It's simpler than that. Draw a circle of radius 1, and draw two lines through the center. The distance along the circumference between those lines is the angle between them in radians. If you really want to remove the multiplicative identity as a magic number, you can define the radian angle as the ratio of the subtended circumference over the radius.

IMO this is at least the most accessible argument for why radians are special, and while I don't pretend to understand complex exponentiation, I expect it's the root of why other math involving radians turns out nicely.

The author makes the point that turns allow for exact representation of many commonly used angles, but with binary floating point, many common angles (1/6 of a turn, for example) are inexact.

This could be addressed by using a whole number other than 1 to represent a turn ... one that is a multiple of 3 (or 3x3) and 5, and while we're at it, 2 (or 2x2x2), so most commonly-used angles are whole numbers! That gives us 360 as the value representing a whole turn.

>1/6 of a turn is inexact

I just want to point out that that is an issue with radians too (pi/3). Whenever this happens I just use that same integer representation (or rational as some poster said) and then remember to multiply by tau before using a math library. With a turns-based library it would only make my life (very slightly) easier

There's no need to represent fractions of a turn as binary fractions, since you don't ever need more than 1 turn. You can represent fractions of a turn as (pair of integer) rationals, and round on the rare occasion that the denominator gets too big.

>since you don't ever need more than 1 turn

Helix.

Indeed, maths never "decreed that sine and cosine have to take radian arguments". But thinking that makes any sort of point is a fundamental misunderstanding of maths.

There are infinitely many sinusoidal functions out there. You can just adjust amplitude, frequency and phase to your heart's content.

Trigonometry basically requires that sine and cosine have specific amplitudes and phases, but gives not one shit about how you map angles to frequency. Degrees are completely arbitrary, but both radians and turns have pretty natural definitions, with turns indeed being the easiest to work with. So far so good.

Calculus does have an opinion on frequency, though. There is exactly one non-trivial pair of sinusoids s(x) and c(x) where c'(x) = - s(x) and s'(x) = c(x), among a bunch of other very useful properties.

When you put calculus and geometry together, s and c are have the same amplitude and phase as sine and cosine from geometry, and the two pairs are exactly the same if you match the frequencies such that the argument is the angle measured in radians. It's just so damned useful to use angles in radians and make everything play together nicely.

> Degrees are completely arbitrary

Degrees are very natural in the context of ancient astronomy/astrology, where you have (1) ~365 days in a year, so that if you look at the path of something that takes a year you get about one degree change per day but with a number that is more easily divisible. (2) approximately 4y, 10y, 8y, 15y, 12y, 30y cycles for the moon and various planets. (3) A calendar with 12 months, 12 zodiac signs. (4) A timekeeping system which breaks days into 24 hours and then uses divisions by sixty for smaller units. (4) A base-sixty number system – from ancient Mesopotamia, which persisted as the standard for astronomical calculations for millennia, only displaced in the very recent past.

All those approximations have error and the behaviour you describe depends on where you are on Earth. Moreover, degrees are not natural from a mathematical perspective.

Out of curiosity, given a degree/calendar/time system could one localize the culture that created it?

That's... convenient for approximately our specific arbitrary position in the universe, but not mathematicallly natural.

My favourite way of handling angles was always with either unsigned char or 16bit unsigned int that was treated as 1/nth of turn. Usually in these cases cos/sin tables were pre-calculated for speed, although that need went away to an extent. As long as as the calculations wrap around on the underlying system, it makes angles much easier to manage, because angle1 + angle2 = angle3 is always within 0 to 255 or 0 to 65535. Unfortunately I mostly work with higher level languages now that have mostly dropped integer types.

If anybody knows how similar calculations can be easily achieved in JS for example, I'd love to hear about it. I'm sure there must be a better way than boundary checks and manual wrap-around.

> If anybody knows how similar calculations can be easily achieved in JS for example

Simply "a = (a + 0x1234) & 0xffffffff;". Or whatever width you require, 0xff or 0xffff. JIT is going to optimize that and-operation away (at least for 32-bit mask 0xffffffff) and keep the integer value internally.

You can also "cast" a var to int by "ORring" 0 with it, like "a |= 0;"

Thank you! This does exactly what I meant. I think this is the best solution for my use-cases. It even handles floating point operations to a correctly, something I didn't expect.

    index = angle1 + angle2 | 0

Will keep things an integer. The | requires casting to int, the 0 makes it a no-op after the cast.

This is from asm.js which had to emulate integers so they looked through what it would take

http://asmjs.org/spec/latest/

God please no, Unreal Engine 3 forced that approach which is why games derived from that engine all had wonky mouse inputs

Wonky mouse inputs? Why?

For the same number of bits, an integer representation of angle is always going to be more precise than a floating point one for angles away from 0. It's also going to be equally precise for the whole circle.

For overflowing integers in JS, you can use single-value long typed arrays. I just checked with an Uint16Array and it wraps back to 0 after 65536.

Thank you! This works great as well for my purposes:

  > a = new Uint16Array(1)
  Uint16Array(1) [ 0 ]
  > a[0]
  0
  > a[0] = a[0] + 65537
  65537
  > a[0]
  1

In JavaScript, I’d stay with floating-point (don’t fight the language if you don’t have to) and use something like x => x - Math.floor(x) to normalize.

Fun fact: PICO-8 only provides turn-based trigonometric functions

https://pico-8.fandom.com/wiki/Sin

> PICO-8 uses an input range of 0.0 to 1.0 to represent the angle, a percentage of the unit circle. Some refer to these units as "turns". For instance, 180° or π (3.14159) radians corresponds to 0.5 turns in PICO-8's representation of angles. In fact, for fans of τ (tau), it's just a matter of dropping τ from your expression.

Back in the early 80's a common thing to do in games on 8 bit computers was to implement sin and cos as lookup tables with the angles being 0-255 or 0-128 or something like that and the result also an integer that was some fixed point representation, so you'd do something like:

  vx = (cos[angle] * speed) >> 8;
  vy = (sin[angle] * speed) >> 8;

Ouch. Less than 1 degree of accuracy? Well, I guess if it’s good enough for Asteroid, it’s good enough for me

The original Asteroids source code has been released, we can look at what it did! (Also, even before that the EPROM images had been disassembled, but looking at the original sources is more fun.)

It indeed used (-128, 128) for (-180°,180°)

For instance, here it is using 64 (written as "40", because hexadecimal) for "PI/2":

    COS:    CLC                     ;COS(A)=SIN(A+PI/2)
            ADC I,40
    ;       JMP SIN

It implements COS in terms of SIN, and SIN wraps everything to be in the domain [0,64] (that is [0°,90°] ) then retrieves that from the lookup table.

code: https://github.com/historicalsource/asteroids/blob/main/A351...

table: https://github.com/historicalsource/asteroids/blob/main/A351...

Pico8 is 128x18 res, so I think the maximum number of visibly unique lines you could draw from one point is 512. You can't even express sub-one-degree (sub-1.422222 really) rotations on Pico8 visually without subsampling etc.

You can always do one cycle of newton-raphson to get nearly double the accuracy with only one extra lookup-multiply-add.

The sin/cos lookup tables would only contain an octant of the circle and use various symmetries to map other values to that range. Thus the resolution is ~0.176 degrees for a 256-entry table.

sin(x) = -sin(-x) = sin(pi - x) = cos(pi/2 - x)

cos(x) = cos(-x) = -cos(pi - x) = sin(pi/2 - x)

Here are the algorithms for PICO-8's sin(), cos() and atan2(), as implemented by the Picolove emulator: https://github.com/picolove/picolove/blob/4b79a3b7ebd1d1bc6c...

Also, since PICO-8 coordinates have their origin in the top-left corner (y goes down), sin()'s result is also inverted.

I agree that this makes sense for the kind of situations that the article talks about. If you only need to express common angles like 90 degrees, 45 and so on, radians are just messy (though in physics, you get used to it).

But in other cases, radians are useful. For example consider the case of small deviations from a direction. If you give it in radians, let's say three mrad (milliradians), it's very easy to estimate how large the error will be over the course of a meter; three mm.

This is just to say: choose the right unit for the job.

To elaborate a bit: that works because sin(x) is very close to x for small x, but only when x is measured in radians.

That's because of the equality relationship between 2π radians and the length of the unit circle perimeter. If one is working with a sine taking in turns, one can just adjust by saying sin(q) ≈ 2π * q for small q.

also known as the fundamental theorem of engineering. Works great for small deformations of stiff materials like steel and concrete.

As already mentioned by others, radians are not arbitrary units for angles; in fact, they are the "natural" "units", so to speak.

By definition, an angle is just the ratio of a circular arc (s) to its radius (r), θ = s/r (as an exercise, imagine how to apply this definition to the angle between two intersecting lines). When the length of the circular arc equals its radius (s = r), the angle subtended is exactly 1 radian; of course, since this is just a ratio, 1 radian is exactly the same as 1 numerically, which is why I put "unit" in quotes earlier -- a radian is not really a unit at all!

A degree, in contrast, equals pi / 180 radians. Of course, since 1 radian = 1, that really just means that 1 deg = pi / 180, similar to how 1%=0.01. Putting this all together, it is perfectly parsable (although not recommended) to say that a $5 burger costs roughly $29000% deg.

The fact that it is natural doesn't make it performant and straightforward for all applications.

For example linear algebra is the natural and general way to handle vectors. However game developers still find quaternions faster and more performant.

>The fact that it is natural doesn't make it performant and straightforward for all applications.

How does changing the scale make anything more or less performant?

If anything, it makes things less performant since to use any hardware supported trig functions you now have to convert your weird angle representation into radians. For simple addition or fractions of your angle, it is just as performant as using angles in any scaling.

> For example linear algebra is the natural and general way to handle vectors. However game developers still find quaternions faster and more performant.

They only use quaternions for a few things, like slerp, and mostly because of gimbal lock.

For everything else they still use linear algebra, and linear algebra is used much, much more than quaternions for nearly any 3d program.

> How does changing the scale make anything more or less performant?

As the article shows, in application code we are multiplying by 2 pi, and the very first step in the optimized assembly is to divide by 2 pi. Therefore changing the scale to what both sides want saves 2 operations.

And why would the optimized version want that division? It is because the next step is to reduce down to a fixed range, then use a lookup table.

> They only use quaternions for a few things, like slerp, and mostly because of gimbal lock.

And yet they still do use them.

> For everything else they still use linear algebra, and linear algebra is used much, much more than quaternions for nearly any 3d program.

Radians are a natural unit to measurements that are based on the radius. Radians are notably not natural to measurements that are based on the circumference, or to any equally divisible arcs of a circle.

A radian is 1turn/2pi.

It is not dimensionless.

A radian, or a turn, has a dimension: angle.

Saying 1radian=1 is just as senseless as saying 1m=1=$1.

It's true that abstract math often drops units because some things (like Taylor series) work nicely in certain units. That doesn't make the unit meaningless.

Street-Fighting Mathematics, thesis/book by Sanjoy Mahajan, shows what amazing things you can die in abstract math if you don't forget units.

It is de juro dimensionless, SI said so, and your government most likely made it official.

https://en.wikipedia.org/wiki/Radian#Dimensional_analysis

https://en.wikipedia.org/wiki/Radian#As_a_SI_unit

I am not sure that the current definitions are consistent or useful, but I myself don't know better.

Sorry, but this is incorrect. An angle is defined through the ratio of two objects with common units; it is dimensionless for the same reason that 5m / 5m is dimensionless. You could argue that radians should only refer specifically to angles, but your own example demonstrates how impracticable that would be: you can't sensibly Taylor expand a trigonometric function (eg, sin(x) ~ x) if the left-hand side and right-hand side have incompatible units.

why radius and not diameter?

It's a good question since "radius" seems somewhat arbitrary, but the reason for defaulting to radius is that the unit circle (radius 1) produces convenient numbers in general in a way that a circle of diameter 1 doesn't. However, that doesn't mean that it's the most parsimonious choice for your particular application.

That was quite convincing actually. I guess we all have this realization at some point in early math education.

Why is it 360 degrees? Mainly because that's a nicely divisible number, no other good reason. Sometimes you find a 400 degree system on calculators but it doesn't seem to be taught anywhere (is it a French thing?)

Then at some point you get shown radians, which relates the arc length to the radius. That somehow seems natural, but it does mean there's going to be this constant lying around somewhere in your calculations.

Parameterizing the angle as a proportion of how big it can be (number of full circles) seems pretty sensible. I mean if you can avoid the constant for at least some of your geometry, then why not?

360 comes from the Babylonians, who used base-60 for numbers much for the reasons you describe (and who gave us the 24-hour day, 60 minute hour and 60-minute second, not to mention the 7-day week).

NATO forces have compasses labelled in mils or milliradians, which are not actually 1/1000 of a radian but as an approximation 1/6400 of a full turn. I still have my Silva military compass from 1989 graduated thus.

https://en.wikipedia.org/wiki/Milliradian

I heard that the reason is 1km away it makes a difference of 1m, so easy to figure out how far enemy troops are from each other.

It is even cooler than that. 1 milliradian is simply the distance (radius) divided by 1000, regardless of the unit of measure. So 1 km / 1000 = 1 m.

At 100 m, 1 milliradian is 1 cm.

At 1000 yards 1 milliradian is 1 yard.

At 1 mile (5280 feet), 1 milliradian is 5.280 feet.

More importantly, it can be used for ranging. The average human height is known, and (usually) so are the sizes of whatever vehicles the other side might be using. Thus, when observing things of known size through some optic with a reticle graduated in mils, you can easily determine the range to them. Which then gives you e.g. the amount of holdover necessary to hit the target with a gun (which can itself be expressed as number of mils on the reticle to aim above).

Wait, like instead of 1/6283.185307 of a turn? That's wild!

(It is off by 1.86%. That much error matters, nowadays, though it wouldn't have, back when.)

And apparently the Warsaw Pact had an even worse 6000, and Sweden a more accurate (but less divisble) 6300.

The 400 system is the grads or gradians, indeed originating from the French revolution.

Nowadays I don't think they're used as the principal unit in any country. Wikipedia does mention it gets some use in specialized fields such as surveying, mining and geology.

They are used indirectly through distance. At the time, the meter was defined as one ten millionth of the distance between the north pole and equator through the Paris meridian. That means that the meter corresponds to 1/100000 of a grad of latitude -- which is better read as "a kilometre is 1/100 of a grad".

This is symmetrical to the nautical mile, which is one minute of arc.

Regarding the 400 "degree" system: they're called gradians and it's part of the centesimal system of angular measures according to Wikipedia. And your French guess was right, they have their origins in the French Revolution. More here: https://en.wikipedia.org/wiki/Gradian

It's 360 degrees because of stars. One degree is how much stars move by one day.

> One degree is how much stars move by one day.

I was going to look that up to confirm it, but then I realized I could prove that statement true using some simple logic I already know. Earth does one cycle around the sun in 365 days. So at midnight looking straight up on a specific star (that is angled perpendicular of the rotating poles of earth) in the sky, the star you would have spotted on that day would appear slightly off the next day at midnight. It would only end up on the same spot on midnight after 365 days. So we are 5 days off, but I am going to believe it is true until someone is correcting me.

Wikipedia agrees with you, technically, except the theory specifically names the sun as the star used. However, the reference is a wolfram alpha article, which only references the book The Elements of Typographic Style. I've never read the book but using the sun position makes sense to me, so I will also choose to believe this until corrected.

Or, as close as made no nevermind, oncet.

I'm so glad someone else finally said this. This article takes the approach of simplicity of code, which I do agree with, but additionally I've been thinking turns would have to be more intuitive and easier to teach (particularly to disinterested teenagers) for YEARS, and I finally feel vindicated at least one person agrees with me.

Turns are really the most neutral way to count an angle. We don't use them for everyday physical things because the numbers we'd deal with would be too small to work well for feeble human minds, hence degrees. But for the mathematical world where we currently use radians, turns make so much more sense.

The mathematical world doesn't only use radians. Parametrizing with a factor of 2*pi is totally common. Sometimes it’s called the winding number which here is called turns.

But yeah the overall point is good. Use language appropriate to the problem at hand.

... and the derivative of sin(x) is ... ?

Re(exp(ix)).

Using degrees, turns, etc instead of radians, is like using 10^y instead of e^x (where y=x/ln(10)). Useful for many practical things, but useless for a lot of math applications, especially involving differential equations, complex numbers etc.

Right - there's a negotiation in terms of complexity. The coefficient baggage has to go somewhere.

For me I don't want to care which units I use (and I'm rarely inspecting the exact angle as a number) - consistency is most important. I'm rarely interested in the precise numerical value of an angle - it's just a thing in the graphics/physics pipeline somewhere.

I don't know if that makes me agnostic about this proposal or conservative.

When you store a value that will be reused, like in an array of points, if every time you walk the array multiplying by a constant, you should seek to store values in such a way that it does not need that treatment. If you are taking sin and cos each time through (presumably, added to some angle), it should be pre-multiplied for the fastest implementation of sin and cos available.

> and the derivative of sin(x) is ... ?

I believe it's cos(x). And I fail to see how that would change regardless of what unit x is expressed in. Sorry, my trig is veeery rusty.

Only when the angle is in radians ...

So now the diameter is 1/pi turns?

No, 2/tau turns, philistine. ;-)

I’m surprised game engines do conversion from degrees to radian to call trigonometric functions. I would have called that bad code in an industrial context. We did everything in radians and converted to degrees only for displaying and input.

It was a lot more natural from us because we are a lot more familiar with radians anyway. I don’t think I have used degrees often since starting high school twenty years ago.

I consider APIs that use degrees essentially broken. (And similarly, APIs that express ratios as numbers in [0, 100].)

But you have to consider that a lot of game engines and related tools are intended for an audience without a strong programming background. You wouldn’t expect a 3D modeling tool to display radians. And if the UI shows degrees, the file format would better use degrees as well to avoid rounding errors. And then maybe you want the scripting layer to use the same values that the UI does. And so on.

Most game engines work in radians under the hood and expose degrees in the UI but still need to glue the UI values to the API which is the code seen in Casey’s Godot example the full context of which is a color picker and h has already been converted from degrees. Godot itself has a bunch of the API in degrees which is pretty bleugh.

It's for convenience of developing tooling. Because the only thing harder than re-framing all of mathematics so that sine and cosine are properly defined in terms of turns would be teaching artists and level designers to believe that a full turn is 2π radians instead of 360 degrees.

Yeah tooling is fine in degrees, which is what I was saying in the first part off my post. It’s more mixing it in the API rather than at the boundaries that is bleugh.

> We did everything in radians and converted to degrees only for displaying and input.

This is generally how game (engine) code works as well. The example in the article is an example of performing that conversion, except with turns instead of degrees.

The post says that programmers convert to radians to call APIs that take radians and then immediately divide by pi before computing the sine. So doing everything in radians would still involve an extra floating point divide compared to the alternative.

No, you are confused. That’s a conversion back to degree after computing the sine. You don’t randomly divide by pi for no reason.

so you're telling me 4/pi is the conversion ratio between degrees and radians, and i am confused?

If you would be so kind, point out the part of the sine implementation that works in degrees: https://github.com/reyoung/avx_mathfun/blob/be617bbcf66993c4...

Saying "rad" are bad units for sin is like saying e is a bad base for logarithms.

The only "bad" thing about rads is that they're not taught early enough so that culturally 45 degrees are not know as pi/4. Then a turn would be known as simply as 2pi (or "a one eighty" as Americans infuriatingly like to call it when someone rotates 360 about themselves)

I'm actually more familiar with the reverse mistake, when people say someone "did a full 360" to mean they have changed their mind/approach.

I suppose the confusion there is with the association of "full 360" with "comprehensive" (as in looking all around, without any blind spots), which is valid.

Hmm. I don't think I have ever witnessed someone describe a full rotation as a one eighty.

> (or "a one eighty" as Americans infuriatingly like to call it when someone rotates 360 about themselves)

I've never heard of this. Even if you fail math, you'll know this from playing Tony Hawk Pro Skater.

There are a lot of comments here saying that radians are the only true way to deal with angles, however I agree with the author of the original article that turns are a legitimate alternative - I just wouldn't use the same language. Instead I would say that the new function I'm calculating is sin(2π t), and maybe also say that t is measured in turns, where (1 turn) = (2π rad).

It still has a nice small angle approximation: sin(2π t) ≈ 2π t for small t (arguably this is easier to interpret than sin(x) ≈ x), and its derivative is slightly more complicated: d/dt sin(2π t) = 2π cos(2π t). But everything is still perfectly workable and makes sense. I don't think you would find a mathematician or engineer surprised to come across functions such as these. (They may prefer to make the standard [1] substitution ω = 2πt if there is going to be a lot of differentiation involved, but this is a choice, not a requirement).

Turns can also be helpful as an intermediate unit which is to be translated both to an angle, and something else (colour, pitch, etc). I used turns internally for a pitch pipe application [2], where a turn became both an angle around a circle (t ↦ (cos(2πt), sin(2πt)), and a pitch moving up and down in equal temperament (t ↦ C4_FREQUENCY * 2^t). That way t=1.5 means either 1.5 octaves higher, or 1.5 full turns around the circle.

What mathematicians or engineers would be unhappy with is finding a redefinition of sin(t) to sin(2π t). Instead, lean into the fact that algebra can be a compact and unambiguous method of communication, and make a new library function called sin2π or something, and document that it calculates sin(2π t). Everyone will know what you mean.

[1]: https://en.wikipedia.org/wiki/Angular_frequency

[2]: https://www.jgibson.id.au/blog/pitch-pipe/

that's a nice naming convention too,

everyone understands that calling

sin2π(x) = sin(2π * x)

I think this whole comment thread is missing the forest for the trees.

The forest here is: know what abstractions your dependencies use and be ready to break your own when you need more speed. This is a vital skill for game developers, where every cycle tends to matter.

> Some time ago, much effort was expended to convince people to replace approximations of “pi” (3.14159…) with approximations of “tau” (6. 28318…).

IMO the effort was simply to replace the use of pi with the use of tau. What does approximation have to do with it?

The author is a software engineer and when he says "people", he implicitly means other software engineers. When he says "replace" he means in code, not in equations.

It's a general challenge of writing on the web that you don't know what context the author assumes and the author doesn't know what context the reader assumes.

In this case, the blog title "Computer, Enhance!" and the article subtitle "Switching away from radians makes code simpler, faster, and more precise." sends a pretty clear signal that this is about programming and not pure mathematics.

For any given article on the web, you can always generate valid criticisms based on the author assuming some context that may not be true for all possible readers. You can't say, "Ice cream is cold" without some commenter pointing out that you're doing a disservice to astronauts for whom ice cream is freeze dried and room temperature.

I find the best way to extract value from writing on the web is to simply try to understand the author's assumed context and go from there.

Right, it is a funny way to say it.

Computationally, we all only ever work with approximations, but when doing mathematics, pi is exact all the way out to the infinity-th digit. To multiply by pi (or any irrational, but particularly transcendental) in a pure mathematical context is to audaciously specify an infinitely long computational process. It is dizzying to contemplate, almost mystical. Sort of like modular arithmetic with an infinitely-precise irrational modulus.

Is any number mod infinity equal to itself?

In the surreal numbers [1], the definition of division and hence modulo applies to all numbers, finite and infinite alike. And for any finite number -omega < x < omega you would indeed have x mod omega == x.

[1] https://en.wikipedia.org/wiki/Surreal_number

What do you want mod infinity to mean?

The point is PI and it’s brother TAU, being transcendental, is always approximated. Which is important to think about if you care about accuracy.

And I think that's the most important part of the argument here. By using radians in this case, you do extra calculation steps only to reduce the accuracy. That seems like a poor investment of the processor's time.

It's a correct description. (Perhaps further refined as "technically correct".) The following are not exact values of π or τ, only approximate ones:

  >>> import math
  >>> math.pi
  3.141592653589793
  >>> math.tau
  6.283185307179586

The effort wanted to replace all uses of Pi (including the ones in math formulas) and not just their use in (floating-point) computer programs where we implement approximations of those formulas.

Sure.

But just because there was {a lot of work to replace all uses of pi with tau} doesn't mean there wasn't {a lot of work to replace all approximate uses of pi with approximate uses of tau in computer programs}.

Better than turns, radians, etc. is an `Angle` newtype AKA wrapper class.

It completely eliminates misinterpretation of the value, miscalculation from [angle = angle + tau*n] as all angles are normalized, is more descriptive, and in a decent language is zero-cost.

Programmers should not be using (radians: float) in modern languages which support wrapper classes

This has nothing to do with the article, and it is equally applicable to degrees, radians, or turns. It neither solves nor hinders the simplicity or performance issues the article was talking about.

I disagree. By wrapping an angle in an Angle class, the internal representation need never be exposed to the programmer.

Rather than every programmer needing to read this blog post to see the performance benefits of using 'turns', instead now just a few library developers need to.

Types are just labels applied to variables. Their only power is type-checking a program to see whether every variable use is consistent. Wrapping something in a type doesn't magically change its value.

Not to mention, Angle is a particularly poor name, since radians, degrees and turns are all different measures of angles.

Say I have this program:

  x : Angle = 90 
  y : Angle = pi/4
  z : Angle = 1/4

  sin : Angle -> Real
  
  sin x //what will this print?
  sin y //how about this?
  sin z // ?

> I disagree. By wrapping an angle in an Angle class, the internal representation need never be exposed to the programmer.

Because nobody will ever instantiate one?

At the end of the day, you're not implementing these as an exercise in hermetic design, you're trying to do arithmetic, presumably on numbers you have.

But what is the underlying representation in the wrapper class?

Does this matter any more than the fact the underlying representation within sin is e.g. an 80 bit number no programming language can give you? `Angle` is a bad name for this example because a newtype should be named after the unit rather than what it models, but once you've newtyped it, what matters is that you call sin with the right one, not the actual representation.

Yes, the entire point of the article is that it does in fact matter.

> what matters is that you call sin with the right one, not the actual representation.

No, the actual representation does matter. At some point, arithmetic operations are being performed and those operations consume CPU cycles. If you care about the performance of the code, you care about having a representation that minimizes the number of those operations.

you can have an internal representation enum and when calling

sin(Angle a){ switch a.representation: rad : sin(a.rad); turn: nsin(a.turn) }

conversion only needed when adding angles of different representation.

Sounds like you're balancing out the performance gains the article talks about with performance losses from branching.

Now your performance is even worse.

Well I don't think they are. Sure they make computing the function simpler. But I would hazard that most people that use these functions are not doing geometry and they are already working with radians. In short if you give any kind of engineer working on any kind of signal processing domain a sine function where sin(1) = 0 you are only going to confuse them.

PS: that's why mathematicians don't use turns they are mostly not doing geometry and radians in that case typically make for better formulas.

> sin(1) = 0 you are only going to confuse them.

Not really, pretty much every single one would assume you just forgot the pi, because everyone writes “sin(1pi)” and never actually “sin(3.14…)” because no one ever writes down numbers in the unit of radians, they already convert to half rotations or full rotations by scaling with pi. Imagine if someone went “nanometers are a dumb unit, because I always write down my numbers as h=342 x 10^-9m” that last part “10^-9m” is just nm. In the same way that sin(1.432pi) might as well just be written sin(1.43*rotation). Arguing for radians is arguing that the most natural way to write it is sin(8.985). Which you will pretty much never see anyone do.

In my example you would not actually write it out but instead have something like this.

[sin(x) for x in sample]

My point is that the trig functions are abstract and useful in multiple domains and in most of these domains turns does not make sense. Turns only makes sense in geometry and maybe some physics but most of the time in these cases you might be better off working with other units, like say quaternions.

The fact is in the vast majority of literature trig functions take rads as arguments, it's the sane default for that reason alone.

I'm interested in this from the perspective of learning maths, rather than writing code (for now).

I've wondered for a few years now whether teaching angles and trig using turns, rather than degrees or radians, would be better from the very beginning. Degrees are arbitrary and based on the numeric preferences of a dead culture, rather than on what's happening on the page or in 3d space. Radians seem better because the units are related to a property of the circle, but they're hard to visualise and reason about because they don't fit a circle in whole numbers. Surely turns are the most clear.

I'm rusty and don't practice maths much. If I did I'd probably have the skills of 14y/o me, for anything outside set theory. I'd definitely do a trigonometry course based on turns if I could find one.

Radians makes the most sense just because (as others have pointed out) pi appears all over in math, and in all those places if you are working with a unit of raidans the math becomes a lot easier. In a few cases turns are easier to work with, but teaching them is a dead end to the vast majority of students who will never work in those domains, and even the few students who work in a domain where turns make sense they will still spend time in other areas of math that works much better in radians.

If mathematicians believed things can’t change or improve, and we have to stick with the status quo only because it’s common and popular, we’d never have had radians in the first place, we’d be stuck with degrees, no? Why assume that people can’t convert between turns and radians as needed, when we all already convert between degrees and radians all the time? Why not imagine a pedagogy that teaches turns and radians and degrees, giving students more flexibility than the current set rather than less?

> but they're hard to visualise and reason about because they don't fit a circle in whole numbers.

I think, unfortunately, that you can't avoid encountering irrational numbers in trig. You would need to constrain yourself to working only with right angles, but in those cases sin and cos are trivial[0] so there would be no need to use trig in the first place.

[0]: 1 or 0, you're either on the right axis or you're not. No circles involved.

> Radians seem better because the units are related to a property of the circle, but they're hard to visualise and reason about because they don't fit a circle in whole numbers.

When I was learning this in school, radians were always expressed as (fraction * pi), not the final number.

If the op had claimed this is only about API design and efficiency, he'd get much less shit because he has a good argument there.

is he getting shit?

This is quite convincing but it would have been more convincing if he'd acknowledged the downsides and explained why it is in radians in the first place. (On balance I think he's probably still right.)

Perhaps we can make new named functions that operate in turns, along the same lines as ln/log. sint, cost, etc. Ok maybe not cost.

We manage OK with cosh for the hyperbolic cosine even though "cosh" is a word. For that matter, "sin" and "cos" are both words, though of course "sin" and "sin" are pronounced differently.

`cost` is a normal variable name in a lot of code though, whereas `cosh` definitely isn't! In fact I bet you can't find a single use of `cosh` in code that isn't talking about hyperbolic cosine.

While I agree that "turns" are much more convenient in some applications than radians, there is no need to invent a new terminology.

For a long time, including the 19th century, the plane angle measurement unit corresponding with 4 right angles, i.e. a complete rotation around a point, has been named "cycle".

That is why in many old physics or engineering books one will find wave numbers measured in "cycles per meter" and frequencies measured in "cycles per second", for example what is now called as a frequency of "10 MHz" was called as a frequency of "10 megacycle per second".

There are 3 important measurement units for the plane angle and each of them is the most convenient unit for a certain class of applications: the right angle, the cycle and the radian.

(An example where the right angle is the most convenient unit is when expressing a complex number with unit modulus as (i^x) instead of the (e ^ (i * x)) that is used with radians.)

Using the inappropriate plane angle measurement unit for an application causes a loss of precision (which can be large for large angles that must be reduced to the 1st quadrant) and introduces extra arithmetic operations that are not needed.

The radian is used much more frequently than it should be used because many standard programming libraries provide only trigonometric functions with arguments in radians, which is a big mistake.

The recent versions of the Floating-Point Arithmetic standard recommend the functions sinPi, cosPi, tanPi, atan2Pi, asinPi, acosPi and atanPi.

This is another serious mistake, because one normally needs either the trigonometric functions of (x * Pi * 2), i.e. with angles measured in cycles, or those of (x * Pi / 2), i.e. with angles measured in right angles, and never the functions of (x * Pi), which are recommended by the standard.

> there is no need to invent a new terminology.

It's not a new terminology: https://en.wikipedia.org/wiki/Turn_(angle)

That page doesn't actually state anywhere when the term 'turns' was actually introduced, the concept yes but not the terminology. As far as I can tell the first references it gives to the term being used is in ISO 80000-3:2006, completed in 2009, although it must have existed earlier because Fred Hoyle appears to have used it and derivatives in 1962. I thought the reference to percentage protractors might be fruitful, but I tracked down the article reference for that from 1922 and it doesn't use the term.

I am partial to the term "windings", defined as not modulo 1 turn.

I e., we are talking here about two very different quantities. Angle is always within a turn, but rotation, using the same units, is not.

https://en.m.wikipedia.org/wiki/Binary_angular_measurement

BAMS has been in use for several decades where fixed point is the norm. DSP for instance.

This isn't new terminology.

https://en.wikipedia.org/wiki/Turn_(angle)

The difference between representation in units of right angles (1/4 cycles), and cycles is just a matter of bumping the exponent up or down two clicks. So cycles / turns and radians suffice.

I suppose it is in solutions to differential equations where radians become important.

Just wait until you find out what cosmologists do with ALL the fundamental constants.

https://www.explainxkcd.com/wiki/index.php/2205:_Types_of_Ap...

This is like complaining about g in F = g * m, in gravitional force formula, and redefining gravitional constant g as 1 and multiplying "gram" by 1/9.8.

Sure it simplifies things for you but you are breaking everything else that used g constant

Or we can redefine seconds perhaps and multiply it sqrt(1/9.8)

See Gaussian-CGS v. SI units [0]. It really confused me going from a CGS physics class to an EE electrodynamics course!

[0] https://en.wikipedia.org/wiki/Gaussian_units

Oh yes. This is definitely a pet peeve of mine. CGS is so much nicer. I did E&M from Jackson before he converted it to MKS, and I still can't keep all those epsilon_0 and mu_0's straight. (Not that it comes up all that much.)

BTW the wikipedia page for angle uses primarily turns. See e.g. this table: https://en.wikipedia.org/wiki/Angle#Measuring_angles .

On the frontend, one thing that I discovered when implementing color spaces into my canvas library was that the CSS HWB standard[1] allows the hue part of a color (which is an angle value) to be supplied supplied as either 'Ndeg', 'Nrad', 'Ngrad' or 'Nturn' values. Other CSS color spaces involving hue don't see to accept 'turn' (though I could be misunderstanding them).

[1] - https://developer.mozilla.org/en-US/docs/Web/CSS/color_value...

You’re misunderstanding things. CSS is typed, and deg/rad/grad/turn are all just angle units; anything that takes an <angle> supports angles in any unit. hsl(0.5turn 100% 50%) is equivalent to hsl(180deg 100% 50%) and #00ffff (and infinite other spellings).

When it was introduced, hsl() only took a <number> for hue, which was interpreted as degrees, but it has had proper <angle> support for over a decade (apart from Opera which only got it with the switch to Chromium in 2013). The current state of affairs is `<hue> = <number> | <angle> | none` (https://drafts.csswg.org/css-color-4/#hue-syntax), and <hue> is used by hsl(), hsla(), hwb(), lch() and oklch().

Ah! Thanks for the explanation. I'll need to fix this in my library.

Is there a Rust library that also takes "turns" (or cycles or something similar) that I can use? I have been wondering (very low-key-ish) about this problem for some years and now that I know this I want to use turns in my code.

> But math never decreed that sine and cosine have to take radian arguments!

To quote a really important comment posted by Eduardo Vasquez on the article:

> [...] all those formulas of derivatives and primitives of trig functions in standard calculus books assume that arguments are expressed in radians. Say, the derivative of sin(x) w.r.t. x is cos(x) --- that is only true if x is in radians. Otherwise, you would get an extra factor, due to the chain rule. [...]

(There are a few comments here that point this out, but they are nested pretty deep so I thought it was worth repeating.)

Lots of things work better in radians: s=r * theta, area = 1/2 theta^2 * r, d(sin(x))/dx = cos(x) (etc, for slopes and numerical algorithms), simpler series approximations and algorithms for computing these and other functions, movement rates of things using gears or wheels are simpler to calculate, radians are dimensionless whereas anything else is not (when used in nearly any physics or math uses), hardware support for lots of related functions, interoperability with legions of existing software, papers, book, and algorithms...

If you like turns you might like

https://en.wikipedia.org/wiki/Gradian

which is ¼₀₀ of a turn. I guess the metric way to do it is use centiturns (4 gradians), milliturns, etc.

On the other hand if you like metric and radians you might like

https://en.wikipedia.org/wiki/Milliradian

> ¼₀₀

{vulgar fraction one quarter}{subscript zero}{subscript zero} is the wrong way of writing this, generally producing a suboptimal result (denominators and subscripts occupy different lines, and the known fractions often have slightly different, more manually-optimised layouts anyway). The proper way is {digit one}{fraction slash}{digit four}{digit zero}{digit zero}: 1⁄400. Won’t render looking like a fraction with split numerator and denominator in all fonts, but it should mostly look better.

A lot of people are getting hung up on the "math never decreed" sentence (not entirely wrongly since it's basically false, and surprising for Casey who has probably forgotten more linalg than I'll ever know), but that's not really the point of the article.

The point is that notationally, turns seem to read better in most code that isn't doing analysis. I'd say this points more to a flaw in our languages than in our function definitions. Of the major general-purpose languages I think only C++ has really taken a shot at implicit unit conversion, which would let you safely and correctly sum a `turn facing` and `degrees delta` and pass the result to a `float sin(radian x)` function and statically ensuring your dimensions remain correct.

Everything else I can think of either makes newtypes too complicated to define, lacks conversion overloads (or more likely lacks operator overloads entirely), or refuses to let you do them implicitly. C++'s approach is certainly too general, but is it really impossible to corral such behavior in a way that's both safe and convenient?

There is also Rational Trigonometry to get rid of cos and sin in general

A Wild Berger has appeared!

The major motivation for radians is arc length parametrization, really. Meaning that in a circle of radius 1 unit (in whatever measurement unit you've chosen), an arc formed by a k-rad angle measures k units. There is an intentional coincidence of angles and arc measurements.

What is the radius of a circle that has a circumference of 1 (as proposed in TFA)? It is 0.5/PI == ~0.15915, which means you are just moving the "problem" elsewhere. I am sure there's a lot of math that is simpler with radius being 1.0 (with some input in radians) vs an input in "turns" and having to deal with a 0.15915 radius.

Yes, agree turns would be so much nicer for many use cases, but I'd like to see which operations it makes worse first :)

If indeed almost every hardware/library implementation of `sin` would lose a multiply by an arbitrary constant by choosing a new input scale, that would convince me too, as long as it was the same scale for all.

But the proposal here would not change the circumference to 1, it's about representing angles in another currency. More often that not when you are doing trigonometry you care more about angles than arclength. The issue stems from thinking angles in terms of arc length.

The angle needing to be used as a length (to be able to use the same scale as a unit radius) is something that naturally happens in a lot of trig algorithms.

It depends whether you care more about the "UI" (the user of the algorithm gets a more pleasant input range to use) vs how convoluted the implementation is (somewhere deep down an extra multiply by 0.15915 was needed).

All I am saying that "turns" are not universally better, they have downsides too.

y’’ = -y

Radians are God’s chosen angular unit. If you want to do mathematics, you have to use radians.

What subfield of mathematics? Surely if you do differential equations, your trigonometric functions will eat radians. But e.g. for geometry, where you do basic arithmetic operations on angles, turns are a bit more convenient than radians. (Radians are not that inconvenient if you denote 6.28 somehow, but then again, why not just use turns.)

The situation is similar to that of the logarithm and exponential functions[0].

There’s a log2 function and a log10 function and they are both useful. But when we talk about the log() function there can be no doubt that it is to base e.

If you want to define a sinT() function that works in turns then that’s totally fine. But the sin() function is defined as taking an argument scaled in radians, because it is mathematically natural.

Mathematically speaking, all trig functions are in radians. When you write sin(90°) the degree symbol ° is a conversion factor. I blame calculators for confusing high schoolers into believing that there is a separate set of functions that work in degrees.

[0] unsurprisingly because Euler’s formula equates the trigonometric and exponential functions.

Parent comment is way too dogmatic for my taste. It even mentions a mythological entity as an appeal to authority.

In my opinion, mathematicians always choose the notation that's more convenient for them, at the moment, for a particular problem.

If a given problem is easier using another form of sin/cos, etc., they will use it, and it will be used without hesitation. In that sense, mathematicians could not be more pragmatic.

However, for many things, as long as the result is correct, they don't care about the operations' computability. Performance is an afterthought because for them (a*п)/п is exactly the same as 'a'. All operations are instantaneous.

Taylor series for example are a perfectly fine final answer in calculus, but to a programmer they are an infinite set of partial approximations that can take any arbitrary time to execute.

This is what makes computer science fascinating =)

Because I didn't see it mentioned yet, this is the same feature that makes the small-angle approximation of sin elegant: sin(x) ≈ x .

With a sin designed for turns, that is just sin(x) ~= 2pi * x or tau * x. Slightly uglier, but still quite simple.

video games don't usually need to take unitless derivatives of sines.

True, but if you are talking about video games in particular you could just build a sin/cos function with different parameters into the game engine.

have a `sin(x)` where the unit of x is radiants and a `sin_turn(x)` where x is expressed in turns.

Video games especially are a great situation to do it like this because they often use a framework (game engine) that was specifically created for this purpose.

> If you want to do mathematics

I'm a software engineer, not a mathematician. Context matters.

Yes! And corresponds nicely with 'spats' for solid angles.

https://en.wikipedia.org/wiki/Spat_(angular_unit)

1 spat = 4 pi steradians.

Turns sound fine.

But they are turns of a circle of a given radius.

So as long as everything conforms to that coordinate system, we're groovy?

Radians (circle fractions) are generally preferred because we can compare, e.g. two planetary orbits, conveniently, no?

Or did I miss something?

> But they are turns of a circle of a given radius. > Radians (circle fractions)

It's the other way around actually. A turn is a turn, no matter the radius of the circle. Radians are the length of the line you need to draw a fraction of a circle with a radius of 1.

(In the end, both are just ways to describe angles and thus independent of any radii... the only effective difference between them is a constant factor of tau or two pi.)

>But they are turns of a circle of a given radius.

No, a revolution is a revolution. If you turn a 1 m wheel by one revolution and a 2 m wheel also by one revolution, both will have turned one revolution, or 2 pi radians. If you roll both of them 2 pi m forward on the ground, one will have turned one revolution, or 2 pi radians, and the other will have turned half a revolution, or pi radians.

Radians are not circle fractions. Radians _divided by 2pi_ are circle fractions. OP is proposing to use circle fractions instead of radians.

In Julia multiple dispatch you could just call

sin(3 turns) which would dispatch the unit to the optimized nsin.

Would the compiler optimize it to be overhead free though?

Yes, it would devirtualize the dispatches for that kind of thing at compile time if the argument type is known at compile time. See how Unitful.jl works. You can then see inside of the LLVM and native code that it swaps in the required functions.

I am a bit surprised with all this commentary that no one has yet mentioned the two variants of Planck's constant - the original one in terms of cycles (turns, here) and the hBar=h/(2pi) that winds up being more common.

Questions like this ultimately have answers related to what formulas are most often deployed - more a sociological question than anything else.

I appreciate the article encouraging programmers to think about API design.

At the same time, I look forward to a future (or present?) where compilers and static analysis tools can point out examples like this; e.g, many examples of calling code multiplying by pi followed by function code dividing by pi.

P.S. This reminds me somewhat of the Department of Redundancy Department.

It definitely makes sense to make computer-trig functions that operate in the [0,1] scaled version of [0,tau]. More efficient.

In my view, because pi crops up unavoidably in math, if you concoct a "unit" to get rid of pi in one place, it will simply crop up somewhere else, perhaps in a denominator.

For instance: The ratio of rise to run for small angles.

Working in optics, radians are such nice units: A milliradian is a millimeter per meter or a "mil" per inch.

> In my view, because pi crops up unavoidably in math, if you concoct a "unit" to get rid of pi in one place, it will simply crop up somewhere else, perhaps in a denominator.

That doesn't mean you shouldn't try to put it in a convenient place.

One way to think of the post is: where you want pi to come up?

With arc length parametrization f(r) = (cos(r), sin(r)), it comes up in the parameter space (one turn: 0 <= r <= 2 pi). If you had the whole thing in terms of turns, you'd instead have (as a primitive) some kind of function g(t); with one full round for 0 <= t <= 1. It'd then have to be true that

f(2 pi t) = g(t) = (cos(2 pi t), sin(2 pi t)).

Pi would come up in the velocity:

f'(r) = (-sin(r), cos(r)) = if

(i u means rotate the vector u by 90 degrees counter-clockwise)

g'(t) = 2 pi f'(2 pi t) = 2 pi (i f(2 pi t)) = 2 pi (i g(t))

Before, you had |f'| = 1. Now you have |g'| = 2 pi.

For classical physics (kinematics and dynamics) applications and classical geometrical applications (curvature, etc), it's really convenient to have that speed term (|f'|) being 1. This is one of the major motivations for arc length parametrization.

By the way, this can't be understated. It really simplifies kinematics, dynamics, geometry, etc, having |f'| = 1 throughout. It's not just for circles. This can be done for an extremely large class of curves and it makes the related math much more understandable and easier to deal with.

For a lot of computer graphics (I believe this is where Casey comes from), you care less about tradicional mathematics for physics and geometry. So you'd rather (maybe) take this pi appearing in the parameter space and push it to the velocity.

In just 24 hours, HN has redefined the units of time [1] and space. Move fast, break things indeed.

What are we disrupting next? I hear the Euro is facing some stability issues.

[1] https://news.ycombinator.com/item?id=32975173

Pi and radians mostly and naturally enter math when we are dealing with both angles and radial distances (e.g. in spherical coordinates). If we choose to normalize in terms of "turns", then angles and circumferences may look natural but radial distances acquire Pi's everywhere.

Radians are just half-turns, so we use turns either way. Some equations look better in turns and some in half-turns, but the math works fine either way.

Instead to decide which is better think of how a new student might learn this intuitively:

How far around is it? 2.5 turns.

This is so much clearer than 5.0 half-turns.

Turns a more clear. No one

> Radians are just half-turns, so we use turns either way.

What? This thread is full of weird statements, but this one is among the weirdest. In what way is a radian a half-turn?

No, radians are pi * half-turns. For example, a 90 degree angle is a quarter-turn (1/4 turns) or pi/2 radians. It is most definitely not 1/2 radians. Equivalently, radians can be said to represent tau turns: 1/4 turns is tau/4 radians.

https://forums.developer.nvidia.com/t/a-more-accurate-and-po...

Justification for using pi units

Yea, I have some macros cysin and cycos that does that, I just call them cycles instead of turns, but it's the same idea.. ofc internally those are still stupid and just multiply by tau..

See:https://doi.org/10.1088/1681-7575/ac7bc2

Who cares? It doesn't matter. No one doing serious work in physics, simulation, etc cares about units at all besides very broad distinctions between systems like natural units vs constructed. Arguing about imperial, metric, pi, tau, etc is 99% bikeshedding by people who don't even do this stuff.

> But math never decreed that sine and cosine have to take radian arguments

Yes it did. The lowest kolmogorov complexity definitions of all trigonometric functions (free from non-integer constants) all take radian-based arguments.

Ooof, you're no true scotsmanning with that bikeshedding argument.

No one doing serious work in physics, simulation

Well, he is doing game engines, so you are right, it is not about "serious work in physics, simulation", it is about simplicity and performance in games.

https://tauday.com/tau-manifesto

Not closely related, but the topic reminds me of this gem of a question from math.SE: Why does "Turn! Turn! Turn!" equal 241217.524881? (It's because of the calculator, but not in an obvious way.)

https://math.stackexchange.com/questions/4207222/why-does-tu...

Turns could be useful if you calculate trig functions with CORDIC. This should simplify the math here.

Bravo! Bravo!! Now if we can just make base10 math the default in modern languages and only let the very few propeller headed weenies that really need it ever pay attention to floating point math and IEEE-754 Hell, we can join the 21st century we were promised.

(Oh, where's my flying car, dammit?!)

IEEE 754 has had decimal (base10) math for close to 15 years now.

A motivation seems to be performance (avoiding useless multiplications followed by divisions by the same factor). I'm not sure that you really "pay" for these multiplications, with code optimization?

I strongly suspect that in most cases, yes, you do. The only time you wouldn't pay this cost is if the multiplication outside of the sin() call and the multiplication inside of it can be constant folded together. That requires the call to sin() to have its code inlined at the callsite. Given how large most sin() implementations are, I would be fairly surprised if it does get inlined.

The only way to answer this is to profile it and see.

Even if it was inlined, I don't think compiler is allowed to rearrange floating-point calculations without -ffast-math or other scary flags.

TIL that the uncanny valley can apply to mathematics.

Old controversy.

Relevant xkcd https://xkcd.com/1292/

Basically it's simpler but it makes most formule more complicated by adding constants all over the place.

Very nice article

Fun fact the radian is a unit in the SI.

"math never decreed that sine and cosine have to take radian arguments!"

This is at best questionable and at worst false.

If you only want to use sin and cos as functions for doing trigonometry, it is true that you can choose whatever angle unit you like and stick with it and it will be fine.

For most other stuff, e.g. differential equations, complex analysis, signal processing and mechanics, it's pretty much inescapable that the zeroes of sin are at integer multiples of pi, and that's that.

Why do they need to be at multiple integers of pi, instead of at half turns?

If you differentiate sin(x) with respect to x then you get cos(x), but only if your trig functions are using radians. Any other unit results in an extra coefficient appearing. That’s not an insurmountable problem, but radians are the fundamental unit here, not just an arbitrary choice.

The main thing to realise is that sin and cos are not fundamentally tools for doing geometry. The fact that you can use them for working out side lengths of triangles or converting polar to cartesian coordinates is somewhat incidental.

It doesn't help that at school our first look at sin and cos is all about adjacent sides and opposite sides in right-angled triangles. It's understandable, because jumping straight into the deep end would be too hard, but it's a bit misleading.

In most mathematical applications, the x in "sin(x)" doesn't even represent an angle, so it doesn't make sense to talk about whether sin and cos are "in degrees or in radians". They're simply functions that crop up as solutions to the differential equation that describes harmonic oscillation; or the imaginary and real parts of e^ix; or exponentiation of certain matrices; or a whole load of other stuff I haven't thought of.

In all those settings, it turns out that sin has zeroes at integer multiples of pi, which forces the convention that a half-turn is an angle of pi, and the definition of radians follows from there. But as I said, for the specific case of basic trig, carrying around a scaling factor and doing everything in degrees is easy enough. Carrying that same scaling factor around in pretty much any other application of sin, cos and related functions would be hell.

Because - numeric precision arguments aside, there's an excellent comment explaining that problem in this thread - it's the only unit of measurement that makes sense for angles.

It provides an easy way to connect the complex exponential with trigonometric functions (and everything you get from that, i.e. Taylor series, nice behavior in diffeqs). You can do the same in degrees as well, but you end up with weird conversion factors with pi in the denominator, a strong indication you should have multiplied by pi to begin with.

It's effectively the same, but cos, sin and others are defined with radians as arguments. Taylor's series expansions are changed, otherwise. So is Euler's formula.

"Turn-based game" gets a new meaning.

τ >> π

>which means the calling code is multiplying by a factor of pi just so the library code can immediately divide it back out again.

Mathematical philosophy aside, that's a pretty compelling argument from a practical perspective. You're doing two unnecessary relatively expensive (multiply/divide) operations in a process that's supposed to be fast.

In practice how likely is it the compiler will optimize away the redundant operations? Is the library boundary typically a barrier to optimization?

If the compiler isn't compiling the library too, I would assume yes.

>But math never decreed that sine and cosine have to take radian arguments!

Ummm, actually it did. The Taylor-series of sine and cosine is the simplest when they work with radians. Euler's formula (e^ix = cosx + isinx) is the simplest when working with radians.

Of course you can work in other units, but you'll need to insert the appropriate scaling factors all over the place.

"Turns" don't generalize to higher dimensions either. With radians you can calculate arc length on a circle by multiplying with the radius. This extends naturally to higher dimensions: a solid angle measured in steradians lets you calculate surface area on a sphere by multiplying with the radius. How do you do the same with "turns" on a sphere? You can't in any meaningful way.

>> Ummm, actually it did. The Taylor-series of sine and cosine is the simplest when they work with radians. Euler's formula (e^ix = cosx + isinx) is the simplest when working with radians.

That's nice, but as the article points out most implementations of trig functions on computers don't use things like Taylor series.

Another terrific use of turns is in calculating angle differences, where you take a difference and just use the fractional part of the result. No bother with wrap around at some arbitrary 2*pi value. Since it wraps at integer values we simply discard the integer part. This can even be for free when using fixed-point math.

That's an obfuscation from the blog post. If you read further down in the code that is mentioned, the actual computation of sin is done by a polynomial expansion in x (radians), not y (turns). The purpose of y is mainly in case x is more than pi, and if so, what the corresponding angle in [0,pi/4) is.

Right, radians are the "natural" units of angle, others generally just make a circle into some integral number of units for convenience, but you always have to go back to radians to actually do calculation.

In the next installment, maybe he'll propose that turns can be limiting because diving up a circle requires the use of fractions, and suggest instead of 1 turn per circle, we make a number that's easily divisible into many integer factors. Maybe 216, or I don't know, 360?

The point of the original post is that depending on your field (e.g. game engine), maybe all the calculations you need can be done easier in the unit of convenience (e.g. sine of a turn is easier to calculate than sine of radian), so if that is the case you should stick with the unit of convenience thru all the layers and forget about converting to radians in your code.

And using fraction of a turn is also a very good option, much better than radians in many cases, especially if you chose a power of two fraction (e.g. 1/256), in this case all the modular arithmetic needed for angles comes for free as simple integer overflow, and lookup tables became a simple array access.

Yes and no.

The Taylor expansion works out like

   sin θ = θ - θ³/₆ + θ⁵/₁₂₀ - θ⁷/₅₀₄₀ + ⋯

if θ is in radians. This is ideal for small θ but if you want to cover, say, 0<θ<2π you are more likely to use something like

https://en.wikipedia.org/wiki/Chebyshev_polynomials

which are optimized across the range. You could rewrite these just as easily to work in degrees as radians.

One of the best ways to calculate sin and cos is CORDIC,

https://en.wikipedia.org/wiki/CORDIC

which is really based on turns, half-turns, quarter-turns and so forth.

> you always have to go back to radians to actually do calculation.

The article actually argues the opposite: that the common implementations of sine and cosine start by converting their radian based arguments to turns or halfturns by dividing by pi.

sin(x) ~~ x only in radians, so honestly that's reason enough.

Once in a while we get programmers wanting to disrupt mathematical notation for whatever reason... Worst I've seen so far was one arguing that equations should be written with long variable names (like in programming) instead of single letters and Greek letters. Using turns because it's a little easier in specific programming cases is just as short-sighted, I'd say, it doesn't "scale out" to the myriad of other applications of angles.

Those perfect radians use 2*pi, aka tau, though, a different math notation issue, where mathematicians have chosen the wrong option (imho) and a case for disrupting that part of math notation, to make radians easier to teach: 1/4th of a circle could be tau/4 radians, 1/8th could be tau/8, etc..., instead of confusing halved factors with radians expressed as amount of pi.

Regarding long variable names: I'd rather have long variable names, than a mathematician using some greek symbol in formulas without telling what the meaning of it is (and it could be different depending on their background). But I have no issues with the single letter variables if they're specified properly.

> Worst I've seen so far was one arguing that equations should be written with long variable names (like in programming) instead of single letters and Greek letters.

That could never work. If anything the words comprising mathematical texts should be defined once and thereafter truncated to their first letter to reduce cognitive burden and facilitate greater comprehension.

c = "could"; d = "don't"; f = "for"; g1 = "go"; g2 = "great"; i = "it"; i2 = "i"; m = "me"; s = "see"; w = "works"; w2 = "what"; w3 = "wrong"

i w g2 f m; i2 d s w2 c g1 w3.

That is the way to do the math, but not the way to write the code.

That said, I would like for my compiler to combine any multiplications involved down to one factor for input to the fastest sin/cos operations the machine has. And, to treat resulting multipliers close enough to 1, 1/2, and 1/4 as exact, and then skip the multiplication entirely.

But the second part is a hard thing to ask of a compiler.

What really bothers me is that mathematicians seemingly never distinguish between doing and presenting mathematics.

You can do your own scribbles with single letters, so do I, it works fine.

But when you present maths in a scientific article, maths book, Wikipedia article or similar, your convenience as a writer should be secondary. Your task is to present information to someone who does not already know the subject. Presenting an equation as six different Greek letters mashed together means that the equation itself convey almost no information. You need a wall of text to make sense of it anyway.

Or just defining the result of division by zero as zero "for safety": https://www.hillelwayne.com/post/divide-by-zero/

It boggles the mind, truly!

That's only for small angles though (stems from Taylor's expansion). With other units, you have a conversion factor, but it remains true enough at small angles.

Whats wrong with long variable names?

LOL

> > But math never decreed that sine and cosine have to take radian arguments!

> Ummm, actually it did.

No, it didn't. Some specific uses looking better with radians does not mean you have to use radians always.

When I first learned sine and cosine, we used degrees, and that worked fine. Later we switched to radians, but there's no reason why you shouldn't use turns, and the article gives a very good argument why in some cases you definitely should.

>Some specific uses looking better with radians does not mean you have to use radians always.

It's not just some specific use cases, it's the majority of cases if you look across all of math and science. Switching to turns would be stupid, especially once you start doing differentiation and integration. The fact that we use radians almost across the board isn't some accident.

The simplicity of the Taylor series of sine and cosine is irrelevant, there are no important applications for those series.

There is only one consequence of those series that matters in practice, which is that when the angles are expressed in radians, for very small angles the angle, its sinus and its tangent are approximately equal.

While this relationship between small angles, sinuses and tangents looks like an argument pro radians, in practice it isn't. There are no precise methods for measuring an angle in radians. All angle measurements are done using an unit that is an integer divisor of a right angle, and then the angles in radian are computed using a multiplication with a number proportional with the reciprocal of Pi.

So the rule about the approximate equality of angles, sinuses and tangents is at best a mnemonic rule, because to apply the rule one must convert the measured angles into radians, so no arithmetic operations can be saved.

"Turns" generalize perfectly to higher dimensions.

To the 3 important units for the plane angle, i.e. right angle, cycle and radian, there are 3 corresponding units for the solid angle, i.e. the right trihedron (i.e. an octant of a sphere), the sphere and the steradian.

The ratio between the right trihedron and the steradian is the same as between the right angle and the radian, i.e. (Pi / 2).

The ratio between the sphere and the right trihedron is 2^3, while that between cycle and right angle is 2^2. In N dimensions the ratio between the corresponding angle units becomes 2^N.

Moreover, while in 2 dimensions there are a few cases when the radian is useful, in 3 dimensions the steradian is really useless. Its use in photometry causes a lot of multiplications or divisions by Pi that have no useful effect.

There is only one significant advantage of the radian, which is the same as for using the Neper as a logarithmic unit, the derivative of the exponential with the logarithms measured in Nepers is the same function as the primitive, and that has as a consequence similarly simple relationships between the trigonometric functions with arguments measured in radians and their derivatives.

Everywhere else where the radian is convenient is a consequence of the invariance of the exponential function under derivation, when the Neper and radian units are used.

This invariance is very convenient in the symbolic manipulation of differential equations, but it does not translate into simpler computations when numeric methods are used.

So the use of the radian can simplify a lot many pen and paper symbolic transformations, but it is rarely, if ever, beneficial in numeric algorithms.

> The simplicity of the Taylor series of sine and cosine is irrelevant, there are no important applications for those series.

The addition theorems for trigonometric functions can easily be shown by the multiplication theorem for Taylor series (and adding two Taylor series). This proof would be more convoluted if the Taylor series were not so easy.

Also, because of the simplicity of their Taylor series, one immediately sees that sin and cos are solutions of the ODE y'' = -y.

Another application of the Taylor series is that by their mere existence, sin and cos (as real functions) have a holomorphic extension.

> there are no important applications for those series.

Excuse me? Have you done any computation in Physics? Have a look at the pendulum equation, for a start...

> there are no important applications for those series.

I cannot believe I just read this.

> So the use of the radian can simplify a lot many pen and paper symbolic transformations, but it is rarely, if ever, beneficial in numeric algorithms.

If only computers could do a bit of symbolic algebraic manipulations before issuing the machine code.

Wait, isn't that what optimizing compilers can do? That requires an optimization across library calls and thus a form of inlining, which doesn't see far fetched for a math library call. Or some optimizations can't be done due to floating point error propagation (which could be relaxed)?

A simple example: suppose we want to compute cos(x)-1 near x=0, with high accuracy, in single precision fp. How to do this? Its very easy: google "taylor series for cosine", lobb off the fist term (1), and you're done.

I already learnt in school to calculate trigonometry using radians or turns depending on the situation. It was part of the general math curriculum in Bavaria. As far as I am aware both are mathematically sound and there is no reason to religiously use one of them over the other. Let your use-case or input parameters decide. The examples given in the article definitely make no sense in radians.

"I already learnt in school to calculate trigonometry using radians or turns depending on the situation. It was part of the general math curriculum in Bavaria. "

Out of interest, when did you go to school in Bavaria and in which grade did you learn about turns? I was in school in Bavaria a long time ago and I don't remember learning about turns there. Could very well be that I forgot or our teacher forgot to teach it.

The shocking thing with some of these articles is somehow the author asked “why do people use radians” and ended up with an answer of “it was an arbitrary decision and the world would be better of not using it”.

I feel a bit of humility would have helped the author and perhaps they would have considered the possibility that they didn’t think of the problem deep enough rather than hastily write a blog post about it.

It speaks to the hubris and the superficiality of thinking for some authors.

The shocking thing about some of these comments is somehow they didn't consider that the original author spoke in a specific context.

Casey didn't say the world would be better with turns instead of radiants. He said that game engine code would be better with turns instead of radiants. Be more charitable.

The writer don’t seem to realise that radian is not an arbitrary unit but a dimensionless one which is defined so that 1rad is actually just 1.

Reading the submission and the comments here, I’m under the impression that trigonometry is not extensively taught in middle schools and high schools in the USA. While I’m slightly envious you might not have to suffer developing powers of cosine and sine but that would explain the lack of familiarity with radian I see here. Am I wrong?

> Am I wrong?

Yes. Trigonometry is extensively taught in the US. People forget this stuff if they don’t use it.

Ask some 30 year old chef in whatever country you fantasize teaches properly to compare and contrast turns vs radians and you’ll get similar responses.

> The writer don’t seem to realise that radian is not an arbitrary unit but a dimensionless one which is defined so that 1rad is actually just 1.

First, I would be cautious about suspecting someone of Casey Muratori's calibre didn't consider something just because he didn't directly addressed it.

Second, the choice of unit is kind of arbitrary, even if the unit itself is not. Radiants are nice because the length of a 1 radiant arc is the same as the length of the radius. But turns are also nice because angles expressed in turns are congruent modulo 1 instead of modulo 2π.

Third, he talks in the context of video games. Such games use code, that have to be read by humans and executed by the CPU. And that's the main point of his article: in this context, expressing stuff in terms of (half) turns reduces the amount of code you have to write & read, reduces the number of multiplications & divisions the CPU has to make, and makes some common operations exact where they were previously approximated.

Do we even care at this point whether the definition of radians is arbitrary or not? I love the elegance of radiants, but for game engine code I'm willing to accept they're just the wrong unit for the job.

> radian is not an arbitrary unit but a dimensionless one

This is by convention, but has been and is still being debated because calling it dimensionless causes some problems. https://en.wikipedia.org/wiki/Radian#Dimensional_analysis

Furthermore, the whole reason to treat radians as dimensionless, the problem, is with angles, not with radians specifically. Degrees are also considered dimensionless. So, a turn could be treated as dimensionless too, with a conversion constant to radians & degrees, just like between degrees and radians.

Of course, the declared dimensionlessness of angles like radians isn’t something generally discussed in pre-college trig courses, that’s a subtle subject that matters more in physics. In my high school trig, we all understood radians to be a unit of angle and never pondered whether angles had dimension.

Also subtle point, but dimensionless doesn’t mean unitless. It’s another separate convention to drop the units when working with radians.

> "I’m under the impression that trigonometry is not extensively taught in middle schools and high schools in the USA. While I’m slightly envious you might not have to suffer developing powers of cosine and sine but that would explain the lack of familiarity with radian I see here. Am I wrong?"

It varies by school, but overall I think this prediction is incorrect. Trigonometry was an important subject in high school — for all of the math, physics, and possibly chemistry courses — and then if you take calculus in university, it's very, very important to learn trigonometry well (or you'll really struggle as a student).

So, even on the off-chance that trigonometry is not taught in high school (which I predict is rare), a first-year student taking calculus in university must learn it on their own time. Good calculus textbooks (e.g. Thomas Calculus) even account for this, having fairly comprehensive textbook sections on what you need to know about trigonometry to succeed in the calculus course.

Most students who therefore took math to pre-calculus or calculus (or physics and possibly chemistry), should therefore have a good exposure to the definition of the radian.

I was a bad student through 8th grade, but managed to get selected for a STEM magnet school. I was supposed to enter 9th grade with Geometry, then algebra II, trig, Calc for the 4 years. But they discovered i'd never passed algebra prior, they put me in algebra, which means i would have finished in trig. Due to a crazy 3.5 years, i never got a high school math education. Calculus makes my eyes glaze over, and all i know about triangles is sohcahtoa.

Every couple of years i try to get some higher math education, but nothing makes sense. It's one of the reasons i [think] i suck at programming - i should note that another reason is i first learned BASIC, then qbasic, then fortran, and then C never made sense to me. At least i can putter around with python and R.

however i can do "basic" math things that generally everyone else has to dig out a calculator app for in my head, percentages, fractions, moving decimals, "making change". Since i suck at higher math, i'm only able to help my kids with basic math, and i try to ensure that they know it fairly well.

>I’m under the impression that trigonometry is not extensively taught in middle schools and high schools in the USA

Basic trig is taught in middle school, but exclusively using degrees. Advanced trig is optional in high school if you take the "hard math" track.

>> The writer don’t seem to realise that radian is not an arbitrary unit but a dimensionless one which is defined so that 1rad is actually just 1.

It's been a while, but I used to have an argument that rad should be a unit. This even plays well in physics where it allows torque to not have the same units as a joule.

Trig is generally called per-calculus in US high schools. It is not a required course, but it is one of the courses everyone on the college track is expected to take.

Though most people haven't used any of that since college and so don't know it very well anymore. I smelled BS when I read the blog, but couldn't put my finger on why - the comment you replied to explained what I knew was the case but couldn't remember.

> I’m under the impression that trigonometry is not extensively taught in middle schools and high schools in the USA

Education quality and quantity vary greatly across the country. Many schools don't require trig at all or lump it in with other classes. I memorized SOH CAH TOA and brute forced a CLEP test (the state of MN is required to allow you to test out of classes and to write a test if one doesn't exist; usually AP and CLEP tests are accepted, and they don't count for/against your GPA).

It's also culturally accepted to "be bad at math," with undertones of defeat and that it's the world doing that to you and not something you can change (maybe the blame lies elsewhere like with how math is taught as a sequence of dependencies and bombing one course makes the rest substantially more difficult). I don't know how many people scrape by a D in trig and subsequently forget it all, but I'd wager it's a lot.

No, like many others you have been confused by the incapacity of those who vote the modifications of the International system of units to decide what kind of units are the units for plane angle and for solid angle: base units or derived units.

A base measurement unit is a unit that is chosen arbitrarily.

A derived measurement unit is one that is determined from the base units by using some relationship between the physical quantity that is measured and the physical quantities for which base units have been chosen.

While there are constraints for the possible choices, the division of the units into base units and derived units is a matter of convention.

Whenever there are relationships between physical quantities where so-called universal constants appear, you can decide that the universal constant must be equal to one and that it shall be no longer written, in which case some base unit becomes a derived unit by using that relationship.

The reverse is also possible, by adding a constant to a relationship, you can then modify its value from 1 to an arbitrary value, which will cause a derived unit to become a base unit for which you can choose whatever unit you like, e.g. a foot or a gallon, adjusting correspondingly the constant from the relationship.

There are 3 mathematical quantities that appear frequently in physics, logarithms, plane angles and solid angles (corresponding to the 1-dimensional space, 2-dimensional space and 3-dimensional space). All 3 enter in a large number of relationships between physical quantities, exactly like any physical quantity.

For each of these 3 quantities it is possible to choose a completely arbitrary measurement unit. Like for any other quantities, the value of a logarithm, plane angle or solid angle will be a multiple of the chosen base unit.

For logarithms, the 3 main choices for a measurement unit are the Neper (corresponding to the hyperbolic a.k.a. natural logarithms), the octave (corresponding to the binary logarithms) and the decade (corrsponding to decimal logarithms).

Like for any physical quantities, converting between logarithms expressed in different measurement units, e.g. between natural logarithms and binary logarithms is done by a multiplication or division with the ratio between their measurement units.

The same happens for the plane angle and the solid angle, for which arbitrary base units can be chosen.

What has confused the physicists is that while for physical quantities like the length, choosing a base unit was done by choosing a physical object, e.g. a platinum ruler, and declaring its length as the unit, for the 3 mathematical quantities the choice of a unit is made by a convention unrelated to a physical artifact.

Nevertheless, the choices of base units for these 3 quantities have the same consequences as the choices of any other base quantities for the values of any other quantities.

Whenever you change the value of a measurement unit you obtain a new system of units and all the values of the quantities expressed in the old system of units must be converted to be correct in the new system of units.

The fact that the plane angle is not usually written in the dimensional equations of the physical quantities in the International System of Units, because of the wrong claim that it is an "adimensional" quantity, is extremely unfortunate.

(To say that the plane angle is adimensional because it is a ratio between arc length and radius length is a serious logical error. You can equally well define the plane angle to be the ratio between the arc length and the length of the arc corresponding to a right angle, which results in a different plane angle unit. In reality the value of a plane angle expressed in radians is the ratio between the measured angle and the unit angle. The radian unit angle is defined as an angle where the corresponding arc length equals the radius length. In general, the values of any physical quantity are adimensional, because they are the ratio between 2 quantities of the same kind, the measured quantity and its unit of measurement. The physical quantities themselves and their units are dimensional.)

In reality, the correct dimensional equations for a very large number of physical quantities, much larger than expected at the first glance, contain the plane angle. If the unit for the plane angle is changed, then a lot of kinds of physical quantity values must be converted.

To add to the confusion, in practice several base units of the 3 mathematical quantities are used simultaneously, so the International System of Units as actually used is not coherent. E.g. the frequency and the angular velocity are measured in both Hertz and radian per second, the rate of an exponential decay can be expressed using the decay constant (corresponding to Nepers) or by the half-life (corresponding to octaves), and so on.

> in the USA

While it might be something you are now realizing, the US is not a single entity in many ways. Rather, it's some 50 states that form a country. Each state has it's own laws and ways of doing things. While there are many similar ways of doing things, none are exactly the same. On top of that, even within the state you'll have different school systems with different policies.

And we aren't even going to discuss going to American schools in Europe.

Use it or lose it. Most people have no reason to need knowledge of trigonometry, so even if they’re taught it they quickly forget it.

I never really learned trigonometry until I started doing game programming in my spare time when suddenly that knowledge and linear algebra became necessary to understand. They only way I learned it was by needing to know it.

In fact, I regularly forget knowledge I don’t need to know. The stuff I do need to know remains fresh in my mind.

any angle unit is dimensionless, radian is no exception

Correct, radians are a "fake" unit made up to understand better formulas (the same way we use types in programming languages)

I agree with you. People confuse their edge case with Math as a whole.

To sum it up: "Computer Science has nothing to do with Math!" ;)

Well it's not exactly surprising, the US is fundamentally built on arbitrary baseless measurement units so getting out of that mindset is probably difficult.

A unit that could be inherently defined by math itself and not a farmer looking at their hands and feet? Preposterous!

> Of course you can work in other units, but you'll need to insert the appropriate scaling factors all over the place.

You probably take out more scaling factors than you introduce.

> Euler's formula (e^ix = cosx + isinx) is the simplest when working with radians.

Euler’s still simple:

e^(2 i pi y) = cosy + isiny

Or if you start noticing c = e^(2 pi) showing up all over the place:

c^iy = cosy + isiny

> How do you do the same with "turns" on a sphere?… You can't in any meaningful way.

Why not do the same thing? One steradian is 1/(4 pi) of a sphere’s solid angle. What if one “steturn” or whatever just covered a full solid angle? And similarly for higher dimensions?

Neither definition seems more natural to me, especially being used to all the factors of 2 and pi that pop over all over the place in the status quo.

I do not see how higher dimensions invalidates the concept. Steradians are replace by a scaled unit-less number that I will called sterturns that goes from 0 to 1.

The sine and cosine that are defined with Taylor series are not the same sine and cosine that are defined for right triangles.

The former are R->R functions, while the latter are defined on Angles (Angle is unfortunately not an SI physical dimension yet, but I expect it soon to change), and they don't care about the measurement unit.

I have no idea what you mean by radians generalizing for higher dimensions, but not turns.

In 2D you can measure the solid angles using steradians.

I guess that turns interpreted as parts of whole circles generalize to parts of whole spheres, and you should divide by 4pi instead of 2pi???

sine and cosine are functions from ℝ->[-1,1]. They don't take in a value which has a unit, or even a dimension, they take in a real number.

sin(x) is precisely the unique function f(x) such that f''(x) = -f(x). Similar to how exp(x) is the unique function g(x) such that g'(x) = g(x).

Sine does not operate on 'angles measured in radians'. It operates on real numbers. It is zero whenever the real number passed in is a multiple of pi. It happens to have applications in relating angles to distances in circles and triangles, and in order to use sine in that context it is useful to introduce the concept of a 'radian' as a specific, constructed angle of a particular size, such that when you express an angle in terms of multiples of a radian, you can just use the sine function to generate useful values.

I was taught that Eulers formula defined complex exponents?

If we used turns for cos and sin we could redefine what e^ix means so it works without radians. From the other answer I guess this is completely wrong...

(I do understand it is nuts to redefine, i'm just interested as a theoretical thought)

Now, how is Eulers formula is deduced? How did we figure out what e^ix means?

One way to understand where the formulas come from is the power series of e^x, remembering that that function is (can be) defined as the function whose derivative is itself. Sin and cos are functions whose second derivative is -sin and -cos respectively. If you plug in ix to the power series for e^x, the complex exponential comes right out.

There are a couple other "paths" to this result, and the choice we have is by far the most elegant.

Oof. This is one of those not-even-wrong cases in which the misunderstanding is revealing.

Math education is so lacking among people who could really benefit from understanding it. Sad state of affairs.

>But math never decreed that sine and cosine have to take radian arguments!

To define trigonometric functions you need angles. Which can be measured in degrees or radians.

If angles, degrees or radians wouldn't matter, those functions would be some ordinary real functions and not called "trigonometric".

https://www.math.net/sine

Which can be measured in degrees, radians, or, as the article recommends, turns.

I use vectors for everything in game programming. If I want to rotate something, Unity has this:

transform.rotation = Quaternion.LookRotation(directionVector);

I never touch sin, cos, pi. When I see a sin function in someone's code, my first instinct is that they're doing something wrong.

The abstraction Unity provides allows you to do neat things without fully understanding the math behind it. But if you don't also learn the math, now you are limited by what those abstractions allow you to do and by the performance cost due to the fact that these abtractions can't make good use of special-case information that would be available to you if you handcrafted the operation.

It is perfectly legitimate to rely on abstractions a lot of the time because it's safe and easy, and _also_ want to roll your own manipulations sometimes, because 1) when you're accustomed to solving weird trig problems with trig, that's the most straightforward way to write the code, or 2) for performance, which, for a game developer, I think ought to be a major concern.

It's super common for people to reach for trig to solve geometry problems when they should be using vector arithmetic instead, eg this answer on SO has to special-case vertical/horizontal lines, which can be avoided entirely if it didn't reach for trig in the first place.

https://stackoverflow.com/a/63673261

I think this is the sort of situation that GP is referring to.

This constant need to redefine the known world around a favourite detail amazes me. Are people that bored?!

(also I itch hearing the idea of redefining interface - and the world - to fit the implementation detail. how about reimplementing using the [0...0.7854] domain instead of the [0...1] if this is such a huge worry after decades of computing - on slower machines - with the natural radian (arc_length/radius) values? I feel Godot engine should fit the world and not the other way around.)

> Math doesn’t require radians. ....What?!?! Circumference, radius and volume, just to name some, try calculate those easily on turns only (without a new constant introduced!).

I think that the author is speaking about their world, in which they regularly encounter a specific use of trigonometric functions which would be simplified (conceptually and computationally) by skipping the conversion from and into radians.

> redefine the known world around a favourite detail

I think that's a good way to think about software optimization. Deep inside nested loops of a game engine (TFA's example code comes from Godot), that's often what you need to do to squeeze some performance characteristic into your hardware.

I think they are trying to expand it beyond their world. They already have this in their world! Shown with examples. Just want it elsewhere as well.

Not everything is about software automation! Especially in this regard where decade long established practices work on legacy hardware and systems. This is ruining/complicating things for some chip of the scope.

Reply on news.ycombinator.com