Hacker News Reader

Comment by taeric | Hacker News Reader

Funny, though I think the main measure most people actually pay attention to is how complicated your code is to do the distance functions.

View on HN

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.

geodesics on ellipsoids of revolution are no small task.

which is why you should just use GeographicLib (or proj, now that it incorporates the same geodesic routines).

Reply on news.ycombinator.com