about::code - my personal blog april 2018

The "radians or degrees" dilemma:

What's wrong with angles - and how to fix them without any overhead

Many frameworks offer function signatures like float sin( float radians ) without strong type safetiness. Although the intent is documented, there are still problems left:

• The compiler will not warn us when we attempt to pass an angle in degrees instead since it can not recognize that as an error. It just sees a float in both cases - the expected input. The consequences can be as huge as caused a rocket crash.

• It is that it is awkward to express an angle in radians instead of degree. For example, a 90 degrees angle corresponds to 1.5707963... radians - which is not very expressive. Usually some converting constants are introduced (effectively equal to writing 90 * 0.01745329252). This is again easy to miss, more to type and still not typesafe.
  

Yet angles are mostly still enforced through consistent rules and documentation. For example, Unity expects an angle in radians for trigonometric functions like the Mathf.Sin/Cos(...)whereas in most other part of the engine a value in degrees is expected. In the UI this is pretty natural (I like to type 180 into the inspector to flip an object instead of typing the value of pi to an arbitrary precision). Those rules are consistent but when we try to take the Mathf.Sin(...) of any euler angle, it's a bug (euler angles in Unity are expressed in degrees an we did not multiply by Mathf.Deg2Rad first). Let's fix this by passing the responsibility to the compiler:

For the C++ version we can introduce a struct called angle that holds an internal representation and can only be constructed with helpers like from_rad(...) or from_deg(...) or e.g. user defined literals. In the spirit of C++ all conversions are constexpr since they involve only a single multiplication that can be done at compiletime where appropriate. The internal representation is templatet (based on our requirements). Radians is usually a good default since the hardware expects this format, so no further conversion is required.

Now we can even introduce a new units, e.g. a normalized system where the value 0.5 would correspond to 180 degrees - or pi radians respectively. The function signature for a sine function that respects any of those arguments is still trivial: float sin( angle a ) and voila, we're typesafe. Inside this function we could still call e.g. a.radians() if we want to use an existing implementation that uses radians.

But most importantly, this does not introduce any overhead as you can see in the corresponding disassembly (click to enlarge):

Here I use a _rad literal for illustration purposes to express pi (180 degrees) which is added to 90 degrees and results in 270 degrees (1.5 x pi). The compiler understands that and produces the same disassembly as if we were to simply print the 270.0f directly. This approach certainly saved me from hunting down subtle bugs without sacrificing readability or performance along the way!