It eschews angles entirely, sticking to ratios. It avoids square roots by sticking to "quadrances" (squared distance; i.e. pythagoras/euclidean-distance without taking square roots).
I highly recommend Wildberger's extensive Youtube channels too https://www.youtube.com/@njwildberger and https://www.youtube.com/@WildEggmathematicscourses
He's quite contrarian, so I'd take his informal statements with a pinch of salt (e.g. that there's no such thing as Real numbers; the underlying argument is reasonable, but the grand statements lose all that nuance); but he ends up approaching many subjects from an interesting perspective, and presents lots of nice connections e.g. between projective geometry, linear algebra, etc.
I wholeheartedly agree with the point being made in the post. I had commented about this in the recent asin() post but deleted thinking it might not be of general interest.
If you care about angles and rotations in the plane, it is often profitable to represent an angle not by a scalar such as a degree or a radian but as a tuple
(cos \theta, sin \theta)
This way one can often avoid calls to expensive trigonometric functions. One may need calls to square roots and general polynomial root finding.
In Python you can represent an angle as a unit complex numbers and the runtime will do the computations for you.
For example, if you needed the angular bisector of an angle subtended at the origin (you can translate the vertex there and later undo the translation), the bisector is just the geometric mean of the arms of the angle
sqrt(z1 * z2)
This is directly related to the field of algebraic numbers.
With complex numbers you get translations, scaled rotations and reflections. Sufficient for Euclidean geometry.
I think this is missing the reason why these APIs are designed like this: because they're convenient and intuitive
Its rare that this kind of performance matters, or that the minor imprecisions of this kind of code matter at all. While its certainly true that we can write a better composite function, it also means that.. we have to write a completely new function for it
Breaking things up into simple, easy to understand, reusable representations is good. The complex part about this kinds of maths is not the code, its breaking up what you're trying to do into a set of abstracted concepts so that it doesn't turn into a maintenance nightmare
Where this really shows up more obviously is in more real-world library: axis angle rotations are probably a strong type with a lot of useful functions attached to it, to make your life easier. For maths there is always an abstraction penalty, but its usually worth the time saved, because 99.9999% of the time it simply doesn't matter
Add on top of this that this code would be optimised away with -ffast-math, and its not really relevant most of the time. I think everyone goes through this period when they think "lots of this trig is redundant, oh no!", but the software engineering takes priority generally
I think over the years I subconsciously learned to avoid trig because of the issues mentioned, but I do still fall back to angles, especially for things like camera rotation. I am curious how far the OP goes with this crusade in their production code.
Have you ended up with a set of self-implemented tools that you reuse?
Doing the same work sticking strictly to vectors and matrices tends to either not work at all or be bulletproof.
The other thing is that trig tends to build complexity very quickly. It's fine if you're doing a single rotation and a single translation, but once you start composing nested transformations it all goes to shit.
Or maybe you're substantially better at trig than I am. I've only been doing trig for 30 years, so I still have a lot to learn before I stop making the same sophomore mistakes.
Agreed. In my view, the method the author figured out is far from intuitive for the general population, including me.
You can then use householder matrix to avoid trigonometry.
These geometric math tricks are sometimes useful for efficient computations.
For example you can improve Vector-Quantization Variational AutoEncoder (VQ-VAE) using a rotation trick, and compute it efficiently without trigonometry using Householder matrix to find the optimal rotation which map one vector to the other. See section 4.2 of [1]
The question why would someone avoid trigonometry instead of looking toward it is another one. Trigonometry [2] is related to the study of the triangles and connect it naturally to the notion of rotation.
Rotations [3] are a very rich concept related to exponentiation (Multiplication is repeated addition, Exponentiation is repeated multiplication).
As doing things repeatedly tend to diverge, rotations are self stabilizing, which makes them good candidates as building blocks for the universe [4].
Because those operations are non commutative, tremendous complexity emerge just from the order in which the simple operations are repeated, yet it's stable by construction [5][6]
[0]https://en.wikipedia.org/wiki/Householder_transformation
[1]https://arxiv.org/abs/2410.06424
[2]https://en.wikipedia.org/wiki/Trigonometry
[3]https://en.wikipedia.org/wiki/Matrix_exponential
[4]https://en.wikipedia.org/wiki/Exponential_map_(Lie_theory)
As with many subject that we learn early in school, it's often interesting revisiting them as adult to perceive additional layer of depth by casting a new look.
With trigonometry we tend to associate it with circle. But fundamentally it's the study of tri-angles.
What is interesting is that the whole theory is "relative". I would reference the wikipedia page for angle but it may make me look like an LLM. The triangle doesn't have positions and orientation baked-in, what matters is the length of the sides and the angle between them.
The theory by definition becomes translation and rotation invariant. And from this symmetry emerge the concept of rotations.
What is also interesting about the concept of angle is that it is a scalar whereas the original objects like lines live in an higher dimension. To avoid losing information you therefore need multiple of these scalars to fully describe the scene.
But there is a degree of redundancy because the angles of a triangle sums to pi. And from this degree of freedom results multiple paths to do the computations. But with this liberty comes the risks of not making progress and going in circles. Also it's harder to see if two points coming from different paths are the same or not, and that's why you have "identities".
Often for doing the computation it's useful to break the symmetry, by picking a center, even though all points could be centers, (but you pick one and that has made all the difference).
Similar situation arise in Elliptic Curve Cryptography, where all points could have the same role, but you pick one as your generator. Also in physics the concept of gauge invariance.
User moves cursor or stick a number of pixels/units. User holds key for a number of ms. This is a scalar: An integer or floating point. I pose this to the trig-avoiders: How do I introduce a scalar value into a system of vectors and matrices or quaternions?
I'm a trig-avoider too, but see it more as about not wiggling back and forth. You don't want to be computing angle -> linear algebra -> angle -> linear algebra... (I.e., once you've computed derived values from angles, you can usually stay in the derived values realm.)
Pro-tip I once learned from Eric Haines (https://erich.realtimerendering.com/) at a conference: angles should be represented in degrees until you have to convert them to radians to do the trig. That way, user-friendly angles like 90, 45, 30, 60, 180 are all exact and you can add and subtract and multiply them without floating-point drift. I.e., 90.0f is exactly representable in FP32, pi/2 is not. 1000 full revolutions of 360.0f degrees is exact, 1000 full revolutions of float(2*pi) is not.
In 2D, using either the angle or its tangent needs a single number. The third alternative is, as others have mentioned, to use a complex number (i.e. the cos and sin couple).
Any of these 3 (angle, tangent of angle and complex number) may be the best choice for a given problem, but for 2D graphics applications I think that using a complex number is more frequently the best. For 3D problems there are 3 corresponding alternatives, using a pair of angles, using a pair of tangents (i.e. coordinate ratios) or using a quaternion.
Specifying directions by the ratio between increments in orthogonal directions, instead of using angular measures, has always been frequent in engineering, since the Antiquity until today.
For something like cursor movement, the ratio between Y pixels and X pixels clearly seems as the most convenient means to describe the direction of movement.
> Now, don't get me wrong. Trigonometry is convenient and necessary for data input and for feeding the larger algorithm. What's wrong is when angles and trigonometry suddenly emerge deep in the internals of a 3D engine or algorithm out of nowhere.
In most cases it is perfectly fine to store and clamp your first person view camera angles as angles (unless you are working on 6dof game). That's surface level input data not deep internals of 3d engine. You process your input, convert it to relevant vectors/matrices and only then you forget about angles. You will have at most few dozen such interactive inputs from user with well defined ranges and behavior. It's neither a problem from edge case handling perspective nor performance.
The point isn't to avoid trig for the sake of avoiding it at all cost. It's about not introducing it in situations where it's unnecessary and redundant.
Fair point, but I think you misspelled Projective Geometric Algebra
You can then calculate a quaternion from the pitch/yaw and do whatever additional transforms you wish (e.g. temporary rotation for recoil, or roll when peeking around a corner).
I find this flow works well because it's like building arbitrarily complex transformation by composing a few operations, so easy to keep in my head. Or maybe I just got used to it, and the key is find a stick with a pattern you're effective with.
So:
> For example, you are aligning a spaceship to an animation path, by making sure the spaceship's z axis aligns with the path's tangent or direction vector d.
Might be:
let ship_z = ship.orientation.rotate_vec(Z_AXIS);
let rotator = Quaternion::from_unit_vecs(ship_z.to_normalized(), path.to_normalized());
ship.orientation *= rotator;
I need to review for the sort of redundant operations it warns about, but from a skim, I'm only using acos for SLERP, and computing dihedral angles, which aren't really the basic building blocks. Not using atan. So maybe OK?
edit: Insight: It appears the use of trig in my code is exclusively for when an angle is part of the concept. If something is only vectors and quaternions, it stays that way. If an angle is introduced, trig occurs. And to the article: For that spaceship alignment example, it doesn't introduce an angle, so no trig. But there are many cases IMO where you want an explicit angle (Think user interactions)
Better use spin groups: they work in every dimension.
If you compute trigonometric functions where the arguments are binary floating-point numbers and you measure the angles in cycles, not in radians (using radians is always a huge mistake in my opinion), the results can be expressed exactly using rational operations and the sqrt function.
You could compute them symbolically and use such symbolic expressions for exact computation, like you use rational numbers.
If you compute them numerically, computing a sqrt does not need more time than a division and correct rounding or computing an arbitrary number of digits are also not more difficult than for division.
Of course, you typically do not care about this, so you can just compute the trigonometric functions approximately, like you also do with division and sqrt, and in a similar time.
No, the acos() call is not expensive at all. There is hardware acceleration.We can calculate acos() with in 12 CPU instructions.
https://git.musl-libc.org/cgit/musl/tree/src/math/i386/acos....
The most impressive math I've seen done during a real-time technical conversation was by someone leveraging comprehensive command of trig identities.
There are certain drawbacks. If the solution involves non-algebraic numbers there is no getting away from the transcendental numbers (that ultimately get approximated by algebraic numbers).
And in any case inverse trig functions are just components of logarithms of quaternions, and trig is components of exponentiating half-axis-angle into quaternions.
I mean I'm perfectly aware that language is a descriptive cultural process etc etc but man this bugs the crap out of me for some reason
If I orient myself I have not taken the subway but the orient express, I’m afraid..