Turns Are Better Than Radians: A Practical Way to Stop Wasting Pi

The moment radians started to feel like busywork

Picture this: you’re implementing a UI color picker (or a cursor knob, or a dial), and you already have an angle value that lives in a clean range like [0, 1]. Zero means “starting position,” 0.25 means “a quarter turn,” 0.5 means “halfway around,” and 1 means “back where you started.”

So why does the code immediately start multiplying by TAU (or 2π) just to call sin() and cos()?

That little conversion shows up everywhere in real engines and apps. It’s not because radians are inherently wrong. It’s because the most common trig functions in codebases are the radian-based versions.

But here’s the better idea: keep your angles in turns (a full circle expressed as 1) and only convert to radians at the edges that truly need it. Turns are not a math gimmick—they can make code simpler, faster, and also more precise in floating-point representations.

Turns and radians, in plain language

Before changing any code, it helps to pin down what these units mean.

Radians (the usual default)

A radian is the standard unit for angles in most math libraries. One full revolution is 2π radians.

Turns (the “one full circle = 1” idea)

A turn is another perfectly legitimate angle unit: 1 turn equals one full circle, and therefore 1 turn = 2π radians. (en.wikipedia.org)

So in turns:

• 0.00 = 0°
• 0.25 = 90°
• 0.50 = 180°
• 1.00 = 360°

This is exactly the structure many interactive values already have: “fraction around the circle.”

The hidden pi tax: converting to radians only to undo it

The key discovery is that trig implementations often do their own internal scaling.

Let’s talk about a typical high-performance sine function. Near the top of many fast trig implementations, you’ll see a constant multiply by something like 4/π (often stored as something called cephes_FOPI). (android.googlesource.com)

That constant exists because the library expects its input in radians and needs to map that input into the function’s internal range reduction / polynomial approximation strategy.

Now look at what happens in your application code:

1. Your angle is already periodic in the range [0, 1] (turns).
2. You multiply by TAU (= 2π) to convert turns → radians.
3. The trig library multiplies by 4/π (and other internal steps).

If you were using pure turns end-to-end, the caller would stop doing that extra conversion multiply. And the library could be written (or wrapped) to accept turns directly, using a simpler, more direct constant set.

Here’s the shape of the wasted work:

// caller has h in [0, 1] where 1 is a full circle
float y = sin(h * TAU); // convert turns -> radians

// but inside sin(), the implementation multiplies by constants
// that were chosen for radian inputs

Once you notice this pattern, it’s hard to unsee it. And it shows up even in well-known engines: Godot defines both TAU and PI as constants for angle work. (github.com)

Why this can also be more precise with floating-point numbers

“Precision” is one of those words that gets used vaguely, so let’s make it concrete.

Most languages store numbers like 0.25 or 0.5 exactly using floating-point formats (like IEEE 754). Under the hood, floats are built on base-2 (binary) representation: numbers whose fractional parts can be written as a ratio of integers with denominator a power of two are exactly representable.

Now compare two kinds of angle constants:

• π-based angles (like π/2 for 90°) involve π, which is irrational. Irrational numbers can’t be represented exactly with finite binary digits.
• turn-based angles like 0.25, 0.5, 0.75, etc. are simple fractions of the form 1/2ⁿ and can be represented exactly.

That’s why the [0, 1] turn domain often feels cleaner in practice:

• 90° is exactly 0.25 turns.
• 180° is exactly 0.5 turns.
• Many “dial-like” values become exact fractions instead of “almost” values.

And once your stored representation is exact at those key landmarks, downstream computations behave more predictably. This doesn’t mean every value becomes perfect—real inputs won’t always land on friendly fractions—but it improves the common case.

“Math doesn’t require radians” (and why that matters for code)

It’s tempting to assume sine and cosine must take radians because that’s what math class did. But the deeper truth is: you can define trig functions for whatever parameterization matches your chosen unit.

In other words, radians aren’t a law of physics. They’re a convention baked into widely used library APIs.

So the practical move is to decide where your codebase wants the angle to live.

• If your app naturally represents “fraction of a circle,” turns fit that mental model.
• If your physics engine or external APIs speak radians, convert at the boundary.

That’s a key discipline: don’t scatter conversions everywhere. Do them in one place.

A straightforward migration strategy

A full rewrite of every math call is rarely necessary. The migration usually looks like this.

Step 1: store angles in turns everywhere you control

For example, keep h in [0, 1), representing turns.

Step 2: provide turn-based trig wrappers

If you’re using the standard library trig functions that require radians, you can wrap them:

constexpr float TAU = 6.2831853071795864769f; // 2*pi

inline float sin_turns(float h) {
 return sinf(h * TAU); // convert turns -> radians once per call
}

inline float cos_turns(float h) {
 return cosf(h * TAU);
}

At first, this might seem like you’re still paying the conversion multiply. That’s true.

The real win comes when you stop doing conversions between representations repeatedly across your system. The caller no longer has to think “radians or turns?” every time. The unit stays consistent.

Step 3 (the deeper win): make trig accept turns directly

If you have (or write) a custom trig implementation, accept turns in the function signature and bake the right constants inside.

The benefit is conceptual and mechanical:

• The caller stops multiplying by TAU.
• The implementation uses constants chosen for the turn domain.

You still end up computing sine/cosine, of course. The point is to remove pointless round-trips.

Half-turns are a useful cousin

Turns are nice because they map to your “one full circle = 1” intuition.

But there’s another common choice: half-turns, where full circle = 2 and [0, 2] is one rotation. Half-turns can make some formulas line up with other systems (like symmetrical ranges around 0 depending on how you offset values).

The same theme applies: choose a representation that matches how your values already behave, and stop converting back and forth.

Why this question comes up so often

So why do so many codebases keep converting turns-like values into radians right before calling sine?

Because the default trig APIs are radian-based, and historical conventions are sticky. But once you see the wasted conversion and the floating-point representability differences, turns start looking less like a trend and more like a practical engineering decision.

And the best part is that this isn’t an abstract preference. It shows up as fewer constants in your code, fewer unit-mismatch bugs, and better behavior around common landmark angles like quarter-turns.

The take-away that sticks

Turns don’t replace the math of sine and cosine. They replace a unit conversion reflex.

When your angles naturally live in a periodic range like [0, 1], representing them as turns keeps your code aligned with the real meaning of the value. Conversions to radians become a boundary concern, not a constant background tax.

That small shift—stop thinking in “half a circle,” start thinking in “a whole circle fraction”—tends to make angle-heavy code feel calmer. Less clutter. Fewer pi-tau breadcrumbs. More precise landmarks.

And once it’s there, it’s hard to go back.