Funny, though I think the main measure most people actually pay attention to is how complicated your code is to do the distance functions.
Funny, though I think the main measure most people actually pay attention to is how complicated your code is to do the distance functions.
I've almost never seen a real complexity difference between floating point and fixed point math in a language that supports fixed point either natively or through operator overloading. Yeah, scaling sometimes changes across an operation; but that's the type system's job, it's not actual complexity. And the error analysis is almost always much simpler for the fixed point implementation than the floating point implementation; and anyone writing code doing numeric approximations in any representation without considering numeric stability and doing the error analysis probably isn't worth running software from.
I am a little confused. My assertion is that most languages don't offer fixed point trig functions. Am I wrong on that assertion?
If you have the trig functions already implemented for the fixed point you are doing, what you are saying makes perfect sense to me. But I swear I get challenged on that point every time it comes up, as nobody has a fixed point trig library. (Well, that seems to be the assertion.)
Fixed-point CORDIC is not hard… but a trivial implementation will be slower than a hardware float implementation, true. Several of the micros I work on have a CORDIC accelerator on a (usually only one) low-latency core designed for BLDC control etc, but that’s neither universal, nor general, of course.