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).
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.
srean 5 hours ago [-]
He maybe considered contrarian but his math is sound.
zzless 1 hours ago [-]
With all due respect, no, it isn't. His drivel against set theory shows that he didn't even read the basic axiomatic set theory texts. In one of his papers, he is ranting against the axiom of infinity saying that 'there exists an infinite set' is not a precise mathematical statement. However, the axiom of infinity does not say any such thing! It precisely states the existence of some object than can be thought of as infinite but does not assign any semantics to it. Ironically, if he looked deeper, he would realize that the most interesting set theoretic proofs (independence results) are really the results in basic arithmetic (although covered in a lot of abstractions) and thus no less 'constructive' than his rational trigonometry.
srean 1 hours ago [-]
"Sound" means free of contradiction with respect to the axioms assumed.
If you can derive a contradiction using his methods of computation I would study that with interest.
By "sound" I do not mean probably sound. I mean I have not seen a proof of unsoundness yet.
sublinear 35 minutes ago [-]
> It precisely states the existence of some object than can be thought of as infinite but does not assign any semantics to it
Can you elaborate on this? I think many understand that the "existence of some object" implies there is some semantic difference even if there isn't a practical one.
I really enjoyed Wildberger's take back in high school and college. It can be far more intuitive to avoid unnecessary invocation of calculation and abstraction when possible.
I think the main thrust of his argument was that if we're going to give in to notions of infinity, irrationals, etc. it should be when they're truly needed. Most students are being given the opposite (as early as possible and with bad examples) to suit the limited time given in school. He then asks if/where we really need them at all, and has yet to be answered convincingly enough (probably only because nobody cares).
srean 6 hours ago [-]
This has been some sort of a mix of peeve and a moment of enlightenment of mine when I understood this.
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)
or as a complex number.
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)
Along with stereographic transform and its inverse you can do a lot.
This is directly related to the field of algebraic numbers.
With complex numbers you get translations, scaled rotations and reflections. Sufficient for Euclidean geometry.
2 hours ago [-]
20k 4 hours ago [-]
>poorly designed third party APIs
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
et1337 1 hours ago [-]
Based on my experience writing many games that work great barring the occasional random physics engine explosion, I suspect that trigonometry is responsible for a significant proportion of glitches.
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.
xbar 1 hours ago [-]
Your response is well-grounded--trig is trouble. Angles are often fine, but many 3rd party library functions are not.
Have you ended up with a set of self-implemented tools that you reuse?
cmovq 15 minutes ago [-]
For a graphics programmer acos(dot(x, y)) always raises an eyebrow. Since most of the time you actually want cos(theta) and even when you think you need the angle you probably don’t.
GistNoesis 5 hours ago [-]
I think it boils down to the alternate view of rotations as two successive reflections.
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]
citing the Wikipedia page for trigonometry makes this feel a lot like you just told an LLM the expected comment format and told it to write insightful comments
Ok, this is very interesting, as after pondering my code and the article's main pt, I independently came to the same conclusion that angles are what introduces trig. I agree that maybe people might be using angles as intermediates, but IMO there are cases where they're the most realistic abstraction. For example, how can I map a user's mouse movements, or button presses to a change in rotation without a scalar value? Without trig?
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?
dxuh 4 hours ago [-]
I agree that use of trigonometry is almost always a smell, but e.g. in games there are so many cases where angles are just more useful and intuitive. I just grep-ed for "angle" in a game of mine and I find it for orienting billboard particles (esp. for particles a single angle is much better than a quat for example). Also for an FPS camera controller. It's much simpler to just store a pitch and a yaw and change that with mouse movement, than storing a quat. You can't really look at a quat and know what kind of rotation it represents without opening a calculator. And I also use it for angle "fudging" so if you want to interact with something if you are roughly looking at it, you need to configure an angle range that should be allowed. It just makes sense to configure this as an angle, because we have some intuition for angles. So I guess for computations angles are probably usually wrong, but they are great for intuition (they are low-dimensional and linear in amount of rotation). That makes them a better human interface for rotations. And as soon as you computations start with angles, of course they find their way into the rest of the code.
hrmtst93837 3 hours ago [-]
Storing pitch and yaw breaks down once you want arbitrary camera rolls, or if you need to interpolate between orientations, because of gimbal lock. Using angles for small UI bits or flat objects is fine, but when those billboard particles need more than one axis of freedom, you usually end up needing quats anyway. Quats are opaque, but conversion functions and debug views help when you actually need to read what's going on. Trig shortcuts mostly pay off for simple or highly constrained motion, but scaling them up tends to introduce messy edge cases.
bob1029 30 minutes ago [-]
Quaternions break down for other situations. They cannot represent a rotation greater than 360 degrees. In an engine like Unity (which stores rotation as quats), you can use arbitrary Euler angles in the editor and it will work fine, but the scene file has to store 2 things. There is an additional m_LocalEulerAnglesHint property that covers this edge case.
nananana9 2 hours ago [-]
I'd pretty much always store pitch/yaw for a first/third person controller. This makes it trivial to modify the values in response to input - `pitch += mouse_delta.y` and to clamp the pitch to a sane range (-90 to 90 deg) afterwards.
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).
eska 3 hours ago [-]
Now, don't get me wrong. Trigonometry is convenient and necessary for data input and for feeding the larger algorithm.
the__alchemist 4 hours ago [-]
I think this is more subjective than the author makes it out to be. I take a third approach: You can change out Matrices for Quaternions. Then do almost every operation using these two types, and a few operation between them. The operation implementations are a mix of dot products, quaternion multiplication, trig etc.
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 should break this down into individual interoperations to compare this to the two examples in the article. To start, `from_unit_vecs` is based on the cross product, and `rotate_vec` is based on quaternion-vector multiplication. So no trig there. But `quaternion::from_axis_angle()` uses sin and cos.
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)
the__alchemist 2 hours ago [-]
Update with the big picture: I think the rotationAxisAngle example in the article is fine. The problem isn't that it exists and uses angles/trig: There are legit uses for that function! The problem is that it's not the best tool for aligning the spaceship. So: Problem is not that fn or angles/trig: It's using the wrong tool.
aleph_minus_one 4 hours ago [-]
> You can change out Matrices for Quaternions.
Better use spin groups: they work in every dimension.
the__alchemist 2 hours ago [-]
Hah! We can throw bivectors onto the pile too for the fans!
simonreiff 3 hours ago [-]
Nice article! I'm not a graphics programmer but mathematically it makes full sense that cross-product would be a vast optimization over using `sin()`. From a complexity perspective, the computation of a cross-product reduces to calculating a formal determinant, a fixed number of arithmetic operations, and hence resolves to O(1) complexity. By contrast, computing `sin()` is O(M(n)log(n)) (even though faster algorithms are often possible in practice). See Brent, Fast multiple-precision evaluation of elementary functions (1976).
storus 5 hours ago [-]
In principle, wouldn't a change of basis be all that is needed?
srean 5 hours ago [-]
It's a little more than change of basis, although change of basis is an important part of it. It converts many apparently trigonometric operations into algebraic ones, root finding included.
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).
This is avoiding an common but unnecesary round trip. When your inputs are vectors, angles are an unnecessary intermediate representation. You can substitute the geometric meaning of dot and cross product directly into the Rodrigues matrix and get by with less operations overall. It's more elegant, uses less instructions.
skrebbel 4 hours ago [-]
The point isn't that formula, it's that using angles for parameters or intermediary values is often wasteful.
virgil_disgr4ce 2 hours ago [-]
OK I have a genuine question outside the topic of TFA. Do people really prefer "orientate" over "orient"? This pattern baffles me. You don't get out of the subway and "orientate" yourself, you "orient" yourself.
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
nyeah 2 hours ago [-]
I think Americans tend to say "orient." I think English people tend to say "orientate."
ozgurozkan 1 hours ago [-]
Inigo's core insight here resonates beyond graphics: when you solve a problem at the wrong level of abstraction, you introduce unnecessary roundtrips (acos -> cos cancelling each other out), instability (the clamp-before-acos hack), and obscured semantics. The elegant fix isn't micro-optimization — it's rethinking which primitives actually describe the problem.
We ran into an analogous situation building audn.ai (https://audn.ai), an AI red-teaming platform. The naive approach to finding behavioral vulnerabilities in AI agents is to enumerate attack prompts — essentially computing "angles" by hand. But the real geometric primitive is adversarial pressure: you want a system that directly produces the failure modes without an acos/cos detour through human-crafted prompt lists.
So we built an autonomous Red Team AI (powered by our Pingu Unchained LLM) that generates and runs adversarial simulations in a closed RL loop with a Blue Team that patches defenses in real time. The result — millions of attack vectors without the manual enumeration step — feels a bit like replacing rotationAxisAngle(acos(dot(z,d))) with a direct cross/dot formulation. The "angle" abstraction just falls away.
Anyway, great article. The principle that elegance usually signals you've found the right representation applies pretty broadly.
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.
If you can derive a contradiction using his methods of computation I would study that with interest.
By "sound" I do not mean probably sound. I mean I have not seen a proof of unsoundness yet.
Can you elaborate on this? I think many understand that the "existence of some object" implies there is some semantic difference even if there isn't a practical one.
I really enjoyed Wildberger's take back in high school and college. It can be far more intuitive to avoid unnecessary invocation of calculation and abstraction when possible.
I think the main thrust of his argument was that if we're going to give in to notions of infinity, irrationals, etc. it should be when they're truly needed. Most students are being given the opposite (as early as possible and with bad examples) to suit the limited time given in school. He then asks if/where we really need them at all, and has yet to be answered convincingly enough (probably only because nobody cares).
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
or as a complex number.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
Along with stereographic transform and its inverse you can do a lot.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?
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)
[5]https://en.wikipedia.org/wiki/Geometric_algebra
[6]https://en.wikipedia.org/wiki/Clifford_algebra
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?
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:
I should break this down into individual interoperations to compare this to the two examples in the article. To start, `from_unit_vecs` is based on the cross product, and `rotate_vec` is based on quaternion-vector multiplication. So no trig there. But `quaternion::from_axis_angle()` uses sin and cos.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.
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).
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
We ran into an analogous situation building audn.ai (https://audn.ai), an AI red-teaming platform. The naive approach to finding behavioral vulnerabilities in AI agents is to enumerate attack prompts — essentially computing "angles" by hand. But the real geometric primitive is adversarial pressure: you want a system that directly produces the failure modes without an acos/cos detour through human-crafted prompt lists.
So we built an autonomous Red Team AI (powered by our Pingu Unchained LLM) that generates and runs adversarial simulations in a closed RL loop with a Blue Team that patches defenses in real time. The result — millions of attack vectors without the manual enumeration step — feels a bit like replacing rotationAxisAngle(acos(dot(z,d))) with a direct cross/dot formulation. The "angle" abstraction just falls away.
Anyway, great article. The principle that elegance usually signals you've found the right representation applies pretty broadly.