使用无符号整数需要浮点精度

Question

I'm working with a microchip that doesn't have room for floating point precision, however. I need to account for fractional values during some equations. So far I've had good luck using the old *100 -> /100 method like so:

increment = (short int)(((value1 - value2)*100 / totalSteps));

// later in the code I loop through the number of totolSteps
// adding back the increment to arrive at the total I want at the precise time
// time I need it. 
newValue = oldValue + (increment / 100);

This works great for values from 0-255 divided by a totalSteps of up to 300. After 300, the fractional values to the right of the decimal place, become important, because they add up over time of course.

I'm curious if anyone has a better way to save decimal accuracy within an integer paradigm? I tried using *1000 /1000, but that didn't work at all.

Thank you in advance.

Answer 1

Fractions with integers is called fixed point math.

Try Googling "fixed point".

Fixed point tips and tricks are out of the scope of SO answer...

Example: 5 tap FIR filter

// C is the filter coefficients using 2.8 fixed precision. // 2 MSB (of 10) is for integer part and 8 LSB (of 10) is the fraction part. // Actual fraction precision here is 1/256.

int FIR_5(int* in,    // input samples
          int inPrec, // sample fraction precision
          int* c,     // filter coefficients
          int cPrec)  // coefficients fraction precision
{
    const int coefHalf = (cPrec > 0) ? 1 << (cPrec - 1) : 0; // value of 0.5 using cPrec
    int sum = 0; 
    for ( int i = 0; i < 5; ++i )
    {
        sum += in[i] * c[i];
    }

    // sum's precision is X.N. where N = inPrec + cPrec;
    // return to original precision (inPrec)
    sum = (sum + coefHalf) >> cPrec; // adding coefHalf for rounding
    return sum;
}

int main()
{
    const int filterPrec = 8;
    int C[5] = { 8, 16, 208, 16, 8 }; // 1.0 == 256 in 2.8 fixed point. Filter value are 8/256, 16/256, 208/256, etc.
    int W[5] = { 10, 203, 40, 50, 72}; // A sampling window (example)
    int res = FIR_5(W, 0, C, filterPrec);
    return 0;
}

Notes:

In the above example:

• the samples are integers (no fraction)
• the coefs have fractions of 8 bit.
• 8 bit fractions mean that each change of 1 is treated as 1/256. 1 << 8 == 256 .
• Useful notation is Y.Xu or Y.Xs. where Y is how many bits are allocated for the integer part and X for he fraction. u/s denote signed/unsigned.
• when multiplying 2 fixed point numbers, their precision (size of fraction bits) are added to each other.
• Example A is 0.8u, B is 0.2U. C=A*B. C is 0.10u
• when dividing, use a shift operation to lower the result precision. Amount of shifting is up to you. Before lowering precision it's better to add a half to lower the error.
• Example: A=129 in 0.8u which is a little over 0.5 (129/256). We want the integer part so we right shift it by 8. Before that we want to add a half which is 128 (1<<7). So A = (A + 128) >> 8 --> 1.
• Without adding a half you'll get a larger error in the final result.

Answer 2

Don't use this approach.

New paradigm: Do not accumulate using FP math or fixed point math. Do your accumulation and other equations with integer math. Anytime you need to get some scaled value, divide by your scale factor (100), but do the "add up" part with the raw, unscaled values.

Answer 3

Here's a quick attempt at a precise rational (Bresenham-esque) version of the interpolation if you truly cannot afford to directly interpolate at each step.

div_t frac_step = div(target - source, num_steps);
if(frac_step.rem < 0) {
    // Annoying special case to deal with rounding towards zero.
    // Alternatively check for the error term slipping to < -num_steps as well
    frac_step.rem = -frac_step.rem;
    --frac_step.quot;
}

unsigned int error = 0;

do {
    // Add the integer term plus an accumulated fraction
    error += frac_step.rem;
    if(error >= num_steps) {
        // Time to carry
        error -= num_steps;
        ++source;
    }
    source += frac_step.quot;
} while(--num_steps);

A major drawback compared to the fixed-point solution is that the fractional term gets rounded off between iterations if you are using the function to continually walk towards a moving target at differing step lengths.

Oh, and for the record your original code does not seem to be properly accumulating the fractions when stepping, eg a 1/100 increment will always be truncated to 0 in the addition no matter how many times the step is taken. Instead you really want to add the increment to a higher-precision fixed-point accumulator and then divide it by 100 (or preferably right shift to divide by a power-of-two) each iteration in order to compute the integer "position".

Do take care with the different integer types and ranges required in your calculations. A multiplication by 1000 will overflow a 16-bit integer unless one term is a long. Go through you calculations and keep track of input ranges and the headroom at each step, then select your integer types to match.

Answer 4

Maybe you can simulate floating point behaviour by saving it using the IEEE 754 specification

So you save mantisse, exponent, and sign as unsigned int values.

For calculation you use then bitwise addition of mantisse and exponent and so on. Multiplication and Division you can replace by bitwise addition operations.

I think it is a lot of programming staff to emulate that but it should work.

Answer 5

Your choice of type is the problem: short int is likely to be 16 bits wide. That's why large multipliers don't work - you're limited to +/-32767. Use a 32 bit long int , assuming that your compiler supports it. What chip is it, by the way, and what compiler?