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

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

The most impressive math I've seen done during a real-time technical conversation was by someone leveraging comprehensive command of trig identities.

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)

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