161–170 of 225 posts
Earlier quoted context omitted.
Yes and no. The x in e^ix is to SO(2) what Euler angles are to SO(3).
This really only says that the connection between Euler's formula and Euler angles is that they're both angles. I would agree with that.
The math is definitely not fine with turns, because your Euler formula e^ix = cos x + i sin x no longer holds. We can use a base other than e , namely B = e^2pi which around 535.4916. This doesn't have the nice e properties like d/dx e^x = e^x. The elegant fact that the base of the natural logarithm, which produces an exponential function that is its own derivative, also shows up as the basis for the above Euler's fo…
The author's not talking about doing math, but about porting math into code. Counting turns is the same as counting cycles. People do that all the time. It works fine. And this math is kind of a mess. exp(x) is its own derivative but the log is not. (d/dx)log(x) = 1/x But, agreed, if you're going to do calculus, use radians.
The derivative of log_b x is 1/(x ln b), where ln b is 1 if b is e.
The computational aspect of it is totally compelling. The library routines are already using turns internally, so it is wasteful to go from/to radians when the caller doesn't require it, and many callers can be rewritten not to. Plus the part argument about common angles like multiples of the right angle having to be irrational numbers under radians is also compelling.
Assume people have read the article and understood it.
My gut instinct was that operations like sin, cos, tan, etc, were the kind that would get aggressively inlined by any modern compiler, and then after inlining the redundant conversions between radian/turns would be canceled out by optimization passes. Of course, gut instinct can be wrong, so I checked in godbolt and was surprised to find out that even if I try to force lto, it still doesn't get inlined and remains a…
Also, sin is probably used so much that inlinung would probably inflate binary size significantly.
Earlier quoted context omitted.
> The author's not talking about doing math, but about porting math into code. If your code doesn't look like the math it's "ported" from, the odds of it being bad code go up like 100x
I’ve been writing code for 46 years. Not once have I had to code a derivative. And for all the people who are concerned about how sin' 2πx = 2π cos 2πx, in actual code, it doesn’t matter. Let’s say that I’m writing a basic graphing function and I want to be able to display the slope of the sin curve at any point. I am not going to expose the turn-based units to the user. Caring about slopes implies that I’m doing cal…
You could be using the results of calculus, which became frazzled with gratuitous constants because of poor angle units before anyone wrote any code.
You want to keep all the math in radians until you code the calculations; then figure out how to optimize it with turns where possible.
Let's do a full circle. It all began with replacing frequent occurrence of 2π in calls of sin and cos functions with τ. This post suggests an optimisation by getting rid of τ by getting rid of radians. That way one can get rid of frequent and adjacent radians to degrees conversions and back. I say, let's get rid of sin and cos itself ! Of course I am being over the top here. However, if you represent angle not as a s…
Let's do a full circle. It all began with replacing frequent occurrence of 2π in calls of sin and cos functions with τ. This post suggests an optimisation by getting rid of τ by getting rid of radians. That way one can get rid of frequent and adjacent radians to degrees conversions and back. I say, let's get rid of sin and cos itself ! Of course I am being over the top here. However, if you represent angle not as a s…
If you want a single number (e.g. you are trying to serialize a lot of data), in many contexts you can replace the coordinates (cos θ , sin θ ) with the stereographic projection h = tan ½ θ = sin θ / (1 + cos θ ). Converting back and forth between these representations is cheap and easy: cos θ = (1 − h ²) / (1 + h ²) and sin θ = 2 h / (1 + h ²).
I have used half angles ½θ because there is no ambiguity about the full angle θ if I know it's sin value (and of course this holds for tan ½θ). Tan works better because one does not have to remember to take the correct branch of sqrt(1 - sin^2 θ).
I learned two clever tricks in this discussion: (i) your tan ½θ and (ii) free modular arithmetic by embedding turns in signed integers.
Earlier quoted context omitted.
I can only imagine what a ridiculous problem it would be to try to re-do, for example, the Vincenty formula for distance between two latitude/longitude points on an oblate spheroid (the earth) if it couldn't use radians. https://en.wikipedia.org/wiki/Vincenty%27s_formulae https://www.johndcook.com/blog/2018/11/24/spheroid-distance/ Further, inverse vincenty is pretty much an essential in anything that needs to find t…
I absolutely love how full Wikipedia is of completely useless pages like the Vincenty's Formulae one, where someone has just gone "look this is what it says in my maths textbook" without any explanation. No discussion of why you'd use this over for example the Haversine function, of course, just a straight out copypasta and a demonstration of how clever someone is at the mathematical notation markup. Incidentally you…
If you're going for "turns", then I would go even further and argue that it shouldn't be represented as a float, but rather a fixed point (signed?) integer. With 0x00000000 being 0°, 0x40000000 90°, etc. You get modular overflow for free, and the precision is consistent all around the circle.
Although new to me this seems to be an old trick. The unit has a name -- BRAD.
In the old days of making 8 bit video games we used BRADs of 0-255 - worked well and the wrap was easy.
Oh yeah, in the era of ¼ circle trig tables (cos and maybe tan; inverse (arc) versions as needed) in ROM or Taylor/Maclaurin approximation (with fast integer division) when FPUs were rare. Such tables and tricks mostly fell by the wayside when the 80486DX, 68040, and N64 (VR4300) arrived and SIMD/MIMD systems followed. I miss strict, deterministic unsigned addition overflow. In many modern languages, all kinds of ver…
Most modern (post-2000) languages actually handle this perfectly fine. They have both signed and unsigned types, with exact bit widths and fully specified semantics, which generally match what the hardware is natively capable of, at least on modern processors.
It's languages from the 1990s that make this complicated. There must have been something in the water that motivated language designers in that decade to "simplify" the number system. Maybe this was an overcorrection from even older languages, which generally weren't trying to be clever but were trying to be portable, at a time when a lot of the basics hadn't been nailed down yet, like 8-bit bytes and two's complement.