[jacobolus]

It’s usually possible to re-frame problems to not require trig functions at all.

For instance, you can represent rotations as unit magnitude complex numbers, compose them using complex multiplication, and trivially get whatever trig functions you want out. If you need to compress them for I/O, take the stereographic projection (requires 1 division per point for both forward and inverse transform) and then optionally reduce the precision of the result.

[doubleunplussed]

Construction of a unit complex number though, given an angle, requires trigonometry. Precomputing this and re-using it is identical to precomputing the sine and cosine of that angle and reusing them instead - the complex number itself doesn't simplify anything here other than storing both the sine and cosine in one variable.

[jacobolus]

The only time you need to start with an angle is if a human or other external system is feeding it to you, and the only time you need to convert to an angle is when you need to present the data to a human or other external system.

The point here is that you can usually get rid of evaluating transcendental functions in the middle of the number crunching part of your code, which is where you would care most about saving operations.

[doubleunplussed]

I don't think that's right. A rotation implies an angle. If it's not coming from a human, then you are either hard-coding an angle to rotate by, in which case you need to take sine and cosine of that angle to generate a complex number, or you're getting the rotation that is implied from some coordinates, hard-coded or otherwise. In which case, you need to normalise a complex number - still requiring a square root.

I don't think there's a way to do rotations without transcendental functions (or square roots) that isn't equivalent to merely precomputing the transcendental functions or square roots.

Maybe square roots are faster, in which case you have a point that avoiding transcendental functions is the way to go.

[sheltron]

I think they're referring to quaternions. May require some trig to generate the initial quaternion, but then in your number crunching code you can multiply with other quaternions (representing rotation composition) and then even convert the result to a 3x3 rotation matrix, both with no trig. This is how game engines handle storing 3D rotation.

[jacobolus]

We’re talking about possible representations of a rotation in the plane. The usual representation is “angle measure”, e.g. radians, degrees, or “binary radians”. This representation makes it easy to compose rotations (just add the angle measures), and the binary version is an efficient use of bits, but if you want to do anything else, e.g. rotate some arbitrary vector, then you need to do a bunch of transcendental function evaluations, which is computationally expensive.

I am recommending using the Cartesian (x, y) coordinate representation instead. This is often called a “complex number” x + iy on the “complex unit circle”, or you can think of it as (cosine, sine) if you prefer. Composition of rotations in this representation is still straight-forward: (a + ib)(c + id) = (ac – bd) + i(ad + bc).

If you need to compress this down to one number for transmission or storage, you can take the stereographic projection (“half-angle tangent”), (x, y) ↦ y / (x + 1), and optionally also reduce the precision. This saves you at least half the bits vs. storing the pair of coordinates, and is relatively inexpensive to compute (takes one division per point).

You are right that to normalize an arbitrary vector requires taking a square root. Fortunately, this doesn’t need to be done too often.

As an added bonus, this method generalizes much more easily than angle measure to representing higher-dimensional rotations and points on higher-dimensional spheres. For instance, I recommend using cartesian coordinates (or the stereographic projection for compression) instead of latitude and longitude for storing points on the 2-sphere such as geographical places. Many pieces of mapping software are constantly converting back and forth (implicitly or explicitly) between latitude/longitude vs. cartesian coordinates for computing distances, directions, and areas, finding intermediate points, applying 3-dimensional rotations, clipping shapes, and so on. This is slow and complicated vs. just using Cartesian coordinates as the internal representation.

It is usually unnecessary to compute the angle measure corresponding to a rotation unless communicating with a human. Angle measure is just one of several possible representations, and it’s only the most common because it gets taught to every child.

[abecedarius]

An example, a solar sailing toy: http://wry.me/t/gravity/gravity.html

Yes, there's a sqrt. (And another for gravity.) No trig needed or wanted.

[contravariant]

I don't quite agree. Complex analysis is more than powerful enough to recover the unit complex number corresponding to a specific angle without referencing any kind of trigonometry. Of course you'll have reconstructed the sine and cosine functions that way, but you don't need to use a single trigonometric function or theorem to get there.

[gugagore]

In terms of implementation, what are you not quite agreeing with?