Neo Geo Dev: Fixed Point Numbers

When I was learning retro game dev (mostly Game Boy), I found fixed point very intimidating. Reading stuff like "the player will move at 1.5 pixels per frame, and to store the decimal point we'll use this special format where certain bits represent the fractional part and certain bits represent the integer part" scared the heck out of me when I was still, like, coming to grips with binary representations at all.

Whereas "the player will move at 3 half-pixels per frame" is just a really straightforward conceptualization. The data representation is the same, the code to convert from half-pixels to pixels is the same, but one way of understanding it feels very technical and abstract.

Especially when working in assembly language (like I was), where you don't really have any kind of typing mechanism, it never really made sense to build a fixed-point data type abstraction.

And, to be clear, I'm not trying to give you, specifically, any guff for this; it's as fine an article on fixed-point that there is.

Not really, I have worked on all those kinds of things professionally, in fixed point, floating point, and arbitrary precision where appropriate. You apparently have not.

> Finance software: if you're using floats, you're doing something horribly wrong. All balances are measured in integer multiples of some quantum; depending on the system, that may be cents, it may be 0.1 cents, or it may be 0.01 cents. Gradations finer than that simply do not exist,

I take it you have never actually worked in finance; I have. This is so ludicrously wrong that this is clear.

Your claim might work for a free app that only handles your checkbook. Actual finance software has to do things like deal with multiple currencies, high precision compounded calculations, exchange rates that go to high precision and can handle trillions (4T+ a day goes through exchange markets), and on an on. To show you how ludicrous your claim it, let's do a simple experiment. I'll take a 64-bit double, you take 64 bit fixed point math, and let's compute compound interest (a tiny, tiny, trivial computation) tables. We'll make each input trivially simple (real code would handle vastly more cases). Here's your spec:

P = beginning principal in pennies, say loans from 0 to $100M (which is small, but I'll try to help your case, which will still fail...) R = rate to 0.001, say mult by 1000 so it's an integer for you. C = times compounded per year, 1-365 (again trivial, but this helps your cause) Y = # of years to compound, 1-100 (again smaller than real code must handle, but it helps your case).

Your goal is to compute the amount the principal has grown to each compounding period, and at the end, return the amount rounded to the nearest penny (bankers rounding, or round up, or round down, whatever you can muster).

So let's see your function of form `long scaleFV(long P, long R, long C, long Y)` using fixed point.

An trivially simple version with doubles would look like

    double FV2(long P, long R, long C, long Y)
 {
  long N = C * Y;               //total number of compounding periods
  double p = P;
  double r = R/1000.0;
  while (N-- > 0)
  {
   p += p * r / (100.0 * C); // most trivial thing one can do
  }

  return (long)round(p);
 }
 

Try it. Show your code that uses the claim you so confidently (and incorrectly) claim above.

And remember this is a trivial, tiny part of the real needs for finance codebases. Once you realize how badly you fail at this simple task where the trivial floating point version works, then please stop claiming things you know nothing about.

> and this matters when you have a regulator asking uncomfortable questions

Oh, I take it you have had this happen? Or did you make this up based on zero experience?

> but at least for PCB design, layout is done in fixed point

In a few systems, like KiCAD it is, not it's certainly not for high end professional systems. Try laying out an ASIC with fixed point, where you might have features at the sub-nm level up to several cm, and you need to track error bounds. And once you need to simulate just about anything (SPICE, etc..) all your fixed point fails.

(Note I use KiCAD a lot for PCB design myself for gadgets I sell; it's good for a few things, but not anywhere as good as a high end PCB design and analysis tool you'd want for high freq stuff and getting past FCC requirements for emissions, which I have also done).

> and avoiding edge cases in your geometry kernel from precision issues makes everything much easier

Yes, easier but larger error. There's a reason pro CAD kernels use floating point, not fixed point. Rotating things in fixed point anything other than 90 degree increments has larger errors by orders of magnitude, and soon your squares are not squares, and your intersections end up with all sorts of bad behavior (see some neat discussion on this in Matt Pharr's Oscar winning book PBRT).

And throughout all this, fixed-point is an order of magnitude slower when hardware float is available, such as places KiCAD runs.

> Robotics: maybe this one's just me, but expressing motion control algorithms in fixed point has saved me €1/part on more than a few occasions as a result of being able to use an MCU without hardware floating point. Compared to the €0.20/part saved by muntzing the rest of the circuit, the small amount of additional work was totally worth it.

It is just you. Yes, at some end-point controller you might use fixed point, but the robotics stuff I've done I often also need stuff like inverse kinematics for motion planning (I'd hate to solve Jacobian inverse stuff in fixed point!), done stuff like probabilistic SLAM flavors (also would diverge so badly as fixed point...), use all flavors of Kalman and other filtering to do sensor fusion, used KF and deep learning stuff to get better estimates from 9DOF mag/gyro/accel sensors, and on and on.

So yes, it may be just you, but I don't know anyone working professionally on robotics systems (and I know a few dozen, having worked with them a loooong time, writing, guess what, numerical code for and with them.).

> I made a header-only fixedpoint.h ...

Same, with also parameter for underlying type so I can plug in int32 where available (e.g., ESP32) int16 where it is not (many microchip chips), or even put in yet another custom type like an int64 emulation built on two int32s.... I've got templated versions to do naive mults and divs (which it seems most people do), one that has correct last bit (takes slightly more bit twiddling, but useful if you want a little more precision). And versions to do faster divs for chips that have software emulated divs (because for fixed point, since at the end you're going to rescale the answer, you can make your div much faster than a naive div followed by a shift). So yes, I have been down all this.

Remember, please show your fixed point code that handles the trivial financial code task above, or stop claiming things you apparently have not done and do not understand.

There's also SIMD instructions. Modern CPUs have built-in instructions for handling multiple ints or floats as a vector. If you can get your fixed-point varies to for into 8-bit or 16-bit fields instead of 32, then the same sized vector units can handle more values per instruction.