fixed point arithmetic in modern systems

Question

I'd like to start out by saying this isn't about optimizations so please refrain from dragging this topic down that path. My purpose for using fixed point arithmetic is because I want to control the precision of my calculations without using floating point.

With that being said let's move on. I wanted to have 17 bits for range and 15 bits for the fractional part. The extra bit is for the signed value. Here are some macros below.

const int scl = 18;
#define Double2Fix(x) ((x) * (double)(1 << scl))
#define Float2Fix(x) ((x) * (float)(1 << scl))
#define Fix2Double(x) ((double)(x) / (1 << scl))
#define Fix2Float(x) ((float)(x) / (1 << scl))

Addition and subtraction are fairly straight forward but things gets a bit tricky with mul and div.

I've seen two different ways to handle these two types of operations. 1) if I am using 32 bits then use a temp 64bit variable to store intermediate multiplication steps then scale at the end.

2) right in the multiplication step scale both variables to a lesser bit range before multiplication. For example if you have a 32 bit register with 16 bits for the whole number you could shift like this:

(((a)>>8)*((b)>>6) >> 2) or some combination that makes sense for you app.

It seems to me that if you design your fixed point math around 32 bits it might be impractical to always depend on having a 64bit variable able to store your intermediate values but on the other hand shifting to a lower scale will seriously reduce your range and precision.

questions Since i'd like to avoid trying to force the cpu to try to create a 64bit type in the middle of my calculations is the shifting to lower bit values the only other alternative?

Also i've notice

    int b = Double2Fix(9.1234567890);
    printf("double shift:%f\n",Fix2Double(b));

    int c = Float2Fix(9.1234567890);
    printf("float  shift:%f\n",Fix2Float(c));

    double shift:9.123444
    float  shift:9.123444

Is that precision loss just a part of using fixed point numbers?

Try printf with %.10f for the floating-point display, you'll see all the digits then. Also: docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html — Koshinae
@pablo1977 if I have 32 bits and I use 12.20 12 is the range so for unsigned I can represent numbers from 0 to 4096 or (1*2^12) for signed I can represent -2048 to 2047. That's the range part. Potatoswatter typo on my part. Koshinae that code creates rounding errors as well. — user1610950

Potatoswatter Potatoswatter · Accepted Answer · 2015-07-26T07:52:41

Since i'd like to avoid trying to force the cpu to try to create a 64bit type in the middle of my calculations is the shifting to lower bit values the only other alternative?

You have to work with the hardware capabilities, and the only available operations you'll find are:

Multiply N x N => low N bits (native C multiplication)
Multiply N x N => high N bits (the C language has no operator for this)
Multiply N x N => all 2N bits (cast to wider type, then multiply)

If the instruction set has #3, and the CPU implements it efficiently, then there's no need to worry about the extra-wide result it produces. For x86, you can pretty much take these as a given. Anyway, you said this wasn't an optimization question :) .

Sticking to just #1, you'll need to break the operands into pieces of (N/2) bits and do long multiplication, which is likely to generate more work. There are still cases where it's the right thing to do, for instance implementing #3 (software extended arithmetic) on a CPU that doesn't have it or #2.

Is that precision loss just a part of using fixed point numbers?

log2( 9.1234567890 – 9.123444 ) = –16.25, and you used 16 bits of precision, so yep, that's very typical.

fixed point arithmetic in modern systems

1 Answers