Ditch Radians: Why Trig Should Take 'Turns' on a [0,1] Scale

The tau-vs-pi debate misses the bigger win, argues this piece: in most code, the constant can vanish entirely. The common pattern in game engines and graphics libraries is a value already normalized to [0,1] that gets multiplied by tau (or pi) purely to feed sin() and cos(). But look inside a typical fast trig implementation — the AVX2 example, and essentially every optimized library — and the first thing it does is multiply by 4/pi to convert right back out. The caller scales up so the callee can immediately scale down, a round-trip to radians and back that accomplishes nothing but an extra multiply.

The fix is to parameterize angles in ‘turns,’ where 1.0 is a full circle, 0.5 is 180 degrees, and 0.25 is a right angle. This isn’t a hack — a turn is an established mathematical unit, and nothing in math requires sine and cosine to take radian arguments. Beyond saving the multiply, turns are more numerically precise: common angles like 90, 180, and 270 degrees land on exact floating-point values (0.25, 0.5, 0.75) needing almost no mantissa bits, whereas those same angles in radians can never be represented exactly.

Adopting it is largely a matter of deleting code. Rewriting sin/cos to accept turns usually means changing a single internal constant, and legacy radian-based callers can be preserved with a thin wrapper. Some platforms already ship the pieces — CUDA’s sincospi intrinsic operates on half-turns (a [0,2] range), letting developers drop pi and tau from their code without touching the library at all. The author reports managing whole codebases this way and never missing radians.