4 ms·

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

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?

tromp 4y ago
> 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.
- adammarples 4y ago
  This is not the common "implementation" of sine and cosine, its the common argument h, in his use case, he tends to want to calculate turns and half turns most often. He might be able to refactor his functions to optimize for this, but its not exactly something I would expect to be a good idea for library code, people do want to calculate other angles.
- bonzini 4y ago
  That's just because the power series would take ages to converge for large arguments, so you take advantage of periodicity. But the implementation in a floating point world is a different thing than the definition in an infinite series world. For example, e^x can be implemented by handling the integer and fractional parts separately, for similar reasons. But no one really cares about the functions e^floor(y) and e^(y-floor(y)). They are only useful as part of an implementation trick.
  - wnoise 4y ago
    That's really not the only thing going on. Yes, it allows you to take advantage of periodicity. But many common function approximations work best (i.e. not requiring any transform of the argument) over the interval [-1, 1].
SkeuomorphicBee 4y ago
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.
- jacobolus 4y ago
  If you are making something like a game engine using computer hardware from the past 30 years, you should avoid angle measures to the extent possible. It is much computationally cheaper and more robust (and easier to reason about) to use vector algebra throughout. Then you have no transcendental functions, just basic arithmetic and the occasional square root. You need the dot product and the wedge product (or combined, the geometric product), and derived concepts like vector projection and rejection. If you need to store a rotation, you can use a unit-magnitude complex number z = x + iy, where x = cos θ, y = sin θ, without ever needing to calculate the quantity θ directly. If you need to compress it down to one parameter for whatever reason, use the stereographic projection s = y / (1 + x) = (1 – x) / y. Reverse that by x = (1 – s²) / (1 + s²), y = 2s / (1 + s²). [If starting from angle measure for whatever reason s = tan ½θ, sometimes called the "half-tangent".] The angle measure is the logarithm of the rotation, θi = log z. In some contexts logarithms can be very convenient, but it’s not the simplest or most fundamental representation. With units of "radians" angle measure is the logarithm of base exp(i) [related to the natural logarithm], and with units of "turns" it is the logarithm of base 1 (sort of).
  - uup 4y ago
    I mean that’s all well and good until you have an object in your game and you’re like “I’d like this object to be leaning at 45 degrees, oops I mean 0.70710678118 + i*0.70710678118
PaulHoule 4y ago
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 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 https://en.wikipedia.org/wiki/CORDIC which is really based on turns, half-turns, quarter-turns and so forth.
- adgjlsfhk1 4y ago
  "One of the best ways to calculate sin and cos is CORDIC" This is extremely false. Cordic is 1 bit per iteration, while polynomials (Chebyshev or minmax) converge exponentially faster.
  - adrian_b 4y ago
    You are of course right about the speed, when a fast hardware multiplier is available for the computation of the polynomials. On the other hand with CORDIC it is extremely easy to reach any desired precision, and in cheap hardware it does not require multipliers. So CORDIC may be considered as "one of the best ways" depending on how "best" is defined. Even when developing a polynomial approximation for the fast evaluation of a trigonometric function, it may be useful to use an alternative evaluation method by CORDIC, in order to check that the accuracy of the polynomial approximation is indeed that expected, because for CORDIC it is easier to be certain that it computes what it is intended.
- scythe 4y ago
  CORDIC is not based on radians or turns; it is based on decomposing the angle into a sum of: phi_n = atan(2^-n) and then using an abbreviated sum formula where computing cos(theta + phi_n) depends only on sums and bitshifts. The small-angle approximations sin(x) ≈ x and cos(x) ≈ 1-x^2/2 are the real killer feature of radians, though, because when you can deal with the loss of accuracy you get to avoid using any loops whatsoever. They're also fundamental to understanding simple physical systems like a pendulum.

tromp 4y ago

> 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.

adammarples 4y ago
This is not the common "implementation" of sine and cosine, its the common argument h, in his use case, he tends to want to calculate turns and half turns most often. He might be able to refactor his functions to optimize for this, but its not exactly something I would expect to be a good idea for library code, people do want to calculate other angles.
bonzini 4y ago
That's just because the power series would take ages to converge for large arguments, so you take advantage of periodicity. But the implementation in a floating point world is a different thing than the definition in an infinite series world. For example, e^x can be implemented by handling the integer and fractional parts separately, for similar reasons. But no one really cares about the functions e^floor(y) and e^(y-floor(y)). They are only useful as part of an implementation trick.
- wnoise 4y ago
  That's really not the only thing going on. Yes, it allows you to take advantage of periodicity. But many common function approximations work best (i.e. not requiring any transform of the argument) over the interval [-1, 1].

SkeuomorphicBee 4y ago

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.

jacobolus 4y ago
If you are making something like a game engine using computer hardware from the past 30 years, you should avoid angle measures to the extent possible. It is much computationally cheaper and more robust (and easier to reason about) to use vector algebra throughout. Then you have no transcendental functions, just basic arithmetic and the occasional square root. You need the dot product and the wedge product (or combined, the geometric product), and derived concepts like vector projection and rejection. If you need to store a rotation, you can use a unit-magnitude complex number z = x + iy, where x = cos θ, y = sin θ, without ever needing to calculate the quantity θ directly. If you need to compress it down to one parameter for whatever reason, use the stereographic projection s = y / (1 + x) = (1 – x) / y. Reverse that by x = (1 – s²) / (1 + s²), y = 2s / (1 + s²). [If starting from angle measure for whatever reason s = tan ½θ, sometimes called the "half-tangent".] The angle measure is the logarithm of the rotation, θi = log z. In some contexts logarithms can be very convenient, but it’s not the simplest or most fundamental representation. With units of "radians" angle measure is the logarithm of base exp(i) [related to the natural logarithm], and with units of "turns" it is the logarithm of base 1 (sort of).
- uup 4y ago
  I mean that’s all well and good until you have an object in your game and you’re like “I’d like this object to be leaning at 45 degrees, oops I mean 0.70710678118 + i*0.70710678118

PaulHoule 4y ago

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 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 https://en.wikipedia.org/wiki/CORDIC which is really based on turns, half-turns, quarter-turns and so forth.

adgjlsfhk1 4y ago
"One of the best ways to calculate sin and cos is CORDIC" This is extremely false. Cordic is 1 bit per iteration, while polynomials (Chebyshev or minmax) converge exponentially faster.
- adrian_b 4y ago
  You are of course right about the speed, when a fast hardware multiplier is available for the computation of the polynomials. On the other hand with CORDIC it is extremely easy to reach any desired precision, and in cheap hardware it does not require multipliers. So CORDIC may be considered as "one of the best ways" depending on how "best" is defined. Even when developing a polynomial approximation for the fast evaluation of a trigonometric function, it may be useful to use an alternative evaluation method by CORDIC, in order to check that the accuracy of the polynomial approximation is indeed that expected, because for CORDIC it is easier to be certain that it computes what it is intended.
scythe 4y ago
CORDIC is not based on radians or turns; it is based on decomposing the angle into a sum of: phi_n = atan(2^-n) and then using an abbreviated sum formula where computing cos(theta + phi_n) depends only on sums and bitshifts. The small-angle approximations sin(x) ≈ x and cos(x) ≈ 1-x^2/2 are the real killer feature of radians, though, because when you can deal with the loss of accuracy you get to avoid using any loops whatsoever. They're also fundamental to understanding simple physical systems like a pendulum.