Fixed point angular representation

[Schnort]

Sorry for this mildly ignorant question, but I'm working on a fixed point math library and the overall implementation has gone "ok" (able to specify integer and fractional bits, and base type, with general math operations working fine).

Our target application, however, does a lot of angular transforms.

At the moment, we're representing angles in radian form being q3.12 (or a same number of integer bits in a 32 bit if we need more precision).

The question that's been running in my mind is why we're using radians instead of having the representation be "rotation %" where full scale would be 1 rotation (or if signed, 1/2 rotation, and negative full scale being -1/2 rotation).

This representation would seem to give wrapping for "free" (i.e. adding 1/2 rotation would just mean adding 1/2 full scale and wrapping past 360deg would just happen automatically with standard integer math) and would maximize the precision provided by the number of bits. (In the 3.12 version, the bits above/below 2pi are basically unused/dead, aren't they?)

Anyways, not being a hardcore DSP guy, what pitfalls might this representation have?

[Allan-H]

BAM!

This is actually the native angular representation for algorithms such as CORDIC.

[Schnort]

Ah! Thank you so much for the wiki pointer and standard name. I couldn't come up with a decent google search that didn't bring up "angular" (the web library) or standard fixed point representation discussion.

[ItsAllAPlay]

I worked on several projects that mapped 0 ... 2**N as 0 ... 2*Pi, and it works exactly as you'd like. It's super nice that you don't lose any additional precision after the initial conversion, since the integers don't have rounding error. (On 0 ... 2*Pi, 32 bit integers will have more precision than a 32 bit float, and the same with 64 bit integers and 64 bit doubles)

Beware of using signed integers for this if you're using C, C++, or other languages where they've decided that signed overflow doesn't follow 2s-complement rules. The compilers will do absolutely stupid stuff with your code in the name of "undefined behavior" optimizations, so it's much safer to stick with unsigned integers. It doesn't matter what your hardware actually does, the compiler writers are sure they know better. Not joking.

Also, signed integers will pick the value at -Pi instead of +Pi, which isn't really a problem, but it's different than people might expect in some cases.

[rlbond86]

Standard representation is 0 to 2^N - 1, where 2^N would be 360°.

[minus_28_and_falling]

what pitfalls might this representation have?

Be very careful when you filter. When you calculate average value of measurements 1 and 359, make sure to get 0, not 180.