Fails to mention that radians relates angle to arc length.
There are valid reasons to prefer radians, especially in calculus. The fact that it's related to arc length is something that never (directly) comes up.
Turns are Better than Radians (2022)
21–30 of 225 posts
Re: Turns are Better than Radians (2022)
#22I think I cautiously agree with this notion to some extent, but IMHO the real answer is that it's application-dependent, and if you're writing a low-level trig library and you have to pick one or the other, it really isn't clear to me that turns should win over radians. I expect many systems that use trigonometry would sometimes use small-angle approximations either for efficiency or to bootstrap to the general case.…
I don't have a super-wide gamut of experience here and numerical analysis isn't my specialty, but nearly all trig implementations I've looked into (in both software and hardware) make heavy use of lookup tables and other shortcuts. I've never seen a Taylor series used in a general implementation - not saying it doesn't exist anywhere, but in most cases that I'm familiar with you could support turns just as easily with a different lookup table.
Re: Turns are Better than Radians (2022)
#23Earlier quoted context omitted.
Well, they don't produce the same result in floating point math, I'm afraid. So you'd need to teach your compiler about what your formulas mean and what context you are using them in. (Ie are you actually doing geometry, or is your AI coding agent just trying arbitrary activation functions for your neuronal net experiments and some of them happen to look like geometry?)
It's a mistake to care about equality of floating point numbers [1]. You must usually consider the lower bits of the number as random. I assume you're saying something other than this though? [1] https://en.wikipedia.org/wiki/Machine_epsilon
I think the point is that, from a compiler's perspective, it's not obvious how much you should be allowed to optimise code at the cost of changing the outcomes of floating points maths - do you allow 1e-10, or 1e-6, or 1e-4 level changes? Does your compiler have to run some test calcs to bound the scale of the change introduced by rewriting fp maths? Some compilers will let you opt in to rewriting floating point maths, but that's opt in so users understand that their numeric outputs might change between optimisation levels.
For more, there's a good post on this kind of flag in Rust: https://pythonspeed.com/articles/faster-float-math-rust/
Re: Turns are Better than Radians (2022)
#24Maybe related
Hamilton's theory of turns revisited
Re: Turns are Better than Radians (2022)
#25I think I cautiously agree with this notion to some extent, but IMHO the real answer is that it's application-dependent, and if you're writing a low-level trig library and you have to pick one or the other, it really isn't clear to me that turns should win over radians. I expect many systems that use trigonometry would sometimes use small-angle approximations either for efficiency or to bootstrap to the general case.…
The time where "turns" are really great is when a whole lot of what you're doing is a phase accumulator.
Re: Turns are Better than Radians (2022)
#26I like to store angles as turns in my own code, because (as noted) it makes quarter-turns computable without rounding. OTOH if you need, say, twelfths of a turn, you might want to just store angles as degrees since that’s already common. Michael Spivak, in Calculus (3rd ed p. 301) considers the unit choice to be a property of the function and initially defines sin° and sinʳ (before settling on sin meaning sinʳ) and c…
You generally can’t apply functions to dimensional units. The only thing units can do is be multiplied or divided together. So I can multiply a mass by a distance or divide a distance by a speed, and I can multiply the result by a scalar; but I can’t take the sine of a distance or the logarithm of a time or exponentiate a mass. Those are things I can only do to scalars.
‘But wait!’ You may cry: ‘the formula for a transverse wave varies with the sine of a distance!’
To which I would say no: it varies with the sine of a distance (the horizontal displacement), divided by another distance (the wavelength), divided by 2pi. The distances cancel out and leave a scalar. The sine is taken of that pure scalar; it results in a pure scalar; and then it’s multiplied by another distance (the amplitude) to give you a vertical displacement. Sine is a pure function.
Something else to consider is that the way we combine units with scalars to create dimensional quantities is through multiplication - and it’s not like there’s a simple formula for what a sine of a product is - I can’t determine sin(ab) in terms of sines or other functions of a and b. So if, say, a ‘degree’ were some dimensional unit, sin(90°) would not be something I could calculate - despite knowing sin(90) I don’t know sin(°) - whatever that would mean - and even if I did it gets me no closer to figuring out sin(90°)
Realizing that ° is just a mathematical constant equal to pi/180 solves a lot here.
Re: Turns are Better than Radians (2022)
#27Fails to mention that radians relates angle to arc length.
There are valid reasons to prefer radians, especially in calculus. The fact that it's related to arc length is something that never (directly) comes up.
Every part of calculus with trig functions relies on this fact! The rate of motion along a circle is approximately linear at the same speed when described in radians.
For example when you do a Taylor series expansion the cos/sin are well approximated by x.
Re: Turns are Better than Radians (2022)
#28> But math never decreed that sine and cosine have to take radian arguments!
If you don't use radians you have to add to add conversion factors everywhere to do calculus. Radians are the natural unit for sin/cos just as E is the natural base of the logarithm and exponential functions.
Re: Turns are Better than Radians (2022)
#29And could use fixed-point decimal for more efficiency since can store as integers and use integer hardware for them. So for instance with 32-bits, the 16 most-sig bits store the number of turns and the 16 least-significant bits store the fraction of a turn. Then if you want to wrap angles that exceed 360 degrees back around the circle, you can simply Logical_AND with 0x0000FFFF. And while you are at it, you could just use fixed-point decimal for sine and cos, whereby the maximum of +1 or -1 map to the most positive and most negative integer value. These type of optimizations were common before FPUs were cheap and fast.
Re: Turns are Better than Radians (2022)
#30Earlier quoted context omitted.
Well, they don't produce the same result in floating point math, I'm afraid. So you'd need to teach your compiler about what your formulas mean and what context you are using them in. (Ie are you actually doing geometry, or is your AI coding agent just trying arbitrary activation functions for your neuronal net experiments and some of them happen to look like geometry?)
It's a mistake to care about equality of floating point numbers [1]. You must usually consider the lower bits of the number as random. I assume you're saying something other than this though? [1] https://en.wikipedia.org/wiki/Machine_epsilon
Huh, what? Floating point numbers have a standard, you know. They aren't non-deterministic YOLO numbers.
By default, the compiler has to stick to what the standard requires, and can't just say add arbitrary imprecision.
Your epsilon is what you get when you try to analyse floating point numbers as approximations of real numbers. But they also have an independent life as bit patterns, and the compiler can't just willy-nilly muck around with these bit patterns.