> For computers, you could use a complex number since it's effectively a cache of sin(a) and cos(a), but you often want general affine transformations and not just rotations, so you use a matrix instead.
That makes sense in some contexts but in, say, 2D physics simulations, you don't want general homogeneous matrices or affine transformations to represent the position/orientation of a rigid body, because you want to be able to easily update it over time without breaking the orthogonality constraint.
I guess you could say that your tuple (c, s) is a matrix [ c -s ; s c ] instead of a complex number c + si, or that it's some abstract element of SO(2), or indeed that it's "a cache of sin(a) and cos(a)", but it's simplest to just say it's a unit complex number.
Why use a unit complex number (2 numbers) instead of an angle (1 number)? Maybe it optimizes out the sins and cosses better — I don't know — but a cache is not a new type of number.
There's a significant advantage in using a tuple over a scalar to represent angles.
For many operations you can get rid of calls to trigonometric functions, or reduce the number of calls necessary. These calls may not be supported by standard libraries in minimalistic hardware. Even if it were, avoiding calls to transcendental can be useful.
Because rotations with complex numbers is not just rotations, its rotations+scaling.
The advantage of complex numbers is to rotate+scale something (or more generally move somewhere in a complex plane), is a one step multiplication operation.
If you need to support zoom, scaling shows up very frequently.
I can give an example from real life. A piece of code one of my colleagues was working on required finding a point on the angular bisector. The code became a tangle of trigonometry calls both the forward and inverse functions. The code base was Python, so there was native support of complex numbers.
So you need angular bisector of two points p and q ? just take their geometric mean and you are done. At the Python code base level you only have a call to sqrt. That simplifies things.
That makes sense in some contexts but in, say, 2D physics simulations, you don't want general homogeneous matrices or affine transformations to represent the position/orientation of a rigid body, because you want to be able to easily update it over time without breaking the orthogonality constraint.
I guess you could say that your tuple (c, s) is a matrix [ c -s ; s c ] instead of a complex number c + si, or that it's some abstract element of SO(2), or indeed that it's "a cache of sin(a) and cos(a)", but it's simplest to just say it's a unit complex number.