Where and how is the accuracy lost by doing in C integer multiplication and division and storing the result in integer or float?

Question

For a calculation in a C program, running on ESP32, I have to multiply and divide the following integers in the following way :

150 × 10000 ÷ 155 ÷ 138 × 100 ÷ 220 × 100 which produces 3100.000000 for a float variable and 3100 for a 32-bit unsigned integer.

I tried to test the result of the calculation on https://www.onlinegdb.com/ using the following code :

int main () {
    float calc = 150 * 10000 / 155 / 138 * 100 / 220 * 100 ;
    printf ( "calc = %f\n", calc ) ;    // 3100.000000

    uint32_t calc0 = 150 * 10000 / 155 / 138 * 100 / 220 * 100 ;
    printf ( "calc0 = %u\n", calc0 ) ;  // 3100
}

which again produces 3100.000000 for the float and 3100 for the 32-bit unsigned integer.

If I enter the same numbers in the calculator on my handy or laptop, the result is in both cases 3187,555782226.

So, I have an accuracy loss on the ESP32 of ( if I haven't messed up the formula ) ca. (3187−3100)÷3187×100 ~= 2,73 %

Where and how does the difference come from and is it possible to get the exact result on a 32-bit microcontroller as on the PC ?

Answer 1

You're not losing any precision on your calculator or mobile device. The precise result is 3187.5557822261889583067701... and your mobile device is approximating that quite accurately.

The problem is that in the expression 150 * 10000 / 155 / 138 * 100 / 220 * 100, all multiplications and divisions are between integers. Even if you use this expression to initialize a float, it's too late then; the precision is already lost.

To get a more precise result, make the first operand a float by adding a .f suffix, and all operations will be between floating point numbers then:

#include <stdio.h>
#include <stdint.h>
#include <inttypes.h>

int main(void) {
    float calc = 150.f * 10000 / 155 / 138 * 100 / 220 * 100;
    printf( "calc = %f\n", calc );

    uint32_t calc0 = 150.f * 10000 / 155 / 138 * 100 / 220 * 100;
    // note: PRIu32 expands to the correct format specifier for uint32_t
    printf( "calc0 = %" PRIu32 "\n", calc0 );

    // tip: we can use unsigned long long (ull suffix) and shift all of the
    //      multiplications to the start to minimize precision loss
    //      (unsigned long long is needed to prevent overflow)
    uint32_t calc1 = 150ull * 10000 * 100 * 100 / 155 / 138 / 220; // 1)
    printf( "calc1 = %" PRIu32 "\n", calc1 );
}

Prints:

calc = 3187.555420
calc0 = 3187
calc1 = 3187

See live example

---

¹⁾ Instead of / 155 / 138 / 120, we can also write / (155ull * 138 * 120). The result is guaranteed to be the same.

Answer 2

If your expression has only int terms, it does int calculations, regardless of whether or not it gets assigned to a float afterwards⁽¹⁾. The assignment has no effect on the calculation itself.

For example, the sub-expression 150 * 10000 / 155 will give you the exact value 9677 rather than the more accurate value (around 9677.419).

You need to tell it to do the calculation as a floating point one, this can be done by simply making the first term 150.0 rather than 150.

Keep in mind this will actually do the calculations as double (higher range and precision than float). Then any precision-loss adjustments will be made when that's assigned to the float target. If that's a problem with your (possibly limited) platform, you can still use float in the calculation by using 150f⁽²⁾.

That's also why your "using uint64_t and doing multiplications first" (in one of your comments) didn't help here. That only affects the final type, the calculations are still done with the int type so any overflow would not be avoided. Again, you can fix that by using something like (uint64_t)150 rather than 150 in your expression.

---

⁽¹⁾ The general rule with an expression operand1 operation operand2 is that the two operands are first modified in such a way that they have the same "common real type".

So, for example, two int operands would stay int. For an int and long, the int would be converted to long. The result is then of that same type. This is covered in the ISO (C17) standard under 6.3.1 Arithmetic operands and 6.3.1.8 Usual arithmetic conversions. The former gives the ranks of the various integral types, the latter explains how the conversions are performed in detail.

Importantly here, a float and an int would have the latter "upgraded" to a float before doing the calculation.

---

⁽²⁾ There's a lot of discussion in various net locations about the floating point performance on the EPS32 so double operations may be problematic depending on your needs. But, as with all optimisation issues, you should measure, not guess. You can then intelligently make a cost/benefit decision to choose between speed and range/precision.

Answer 3

Integer division truncates the value towards zero. In the case of 150 * 10000 / 155 the result is 9677.41935484 but becomes 9677, then is divided by 138 which should be 70.126227209 but becomes just 70. The subsequent multiplications amplify the magnitude of the error. In short, integer division costs precision. Possibly this could be mitigated by reordering the calculations, to do the divisions last and thus have fewer multiplications that 'magnify' the errors. Though do be aware of overflows.

Answer 4

In microcontrollers without a FPU you generally want to to stick to fixed point arithmetic and set the accuracy manually. Using float with no FPU present means horrible program performance, since the compiler will then handle floating point through software libs instead. Forget about that and stop taking bad advise from PC programmers.

Fixed point arithmetic isn't rocket science - you need to know the integer limits, elementary school math and a bit of common sense :) Basically it means: multiply first, then divide, because you only lose accuracy during division and integer division truncates all decimals.

In case of unsigned 32, the upper limit is 2^32 - 1 or if you will 4.29 billion. Your worst case calculation should not exceed this value at any point.

NOTE: all integer constants have a type and in case of constants like 150, it's int, which is signed-32 and not really a helpful type. We can either suffix all constants with u or maybe ul to ensure the correct type, or we can make sure that one of the operands is of the correct type, in which implicit promotion will promote the other operand.

If we want 3 decimals, then we'd simply multiply by 10^3 and then rearrange the equation so that we don't hit the upper limit anywhere:

uint32_t calc = 1000; // 3 decimals
    calc *= 150;
    calc *= 10000;
    calc /= 155;
    calc *= 100;
    calc /= 138;
    calc *= 100;
    calc /= 220;
printf("%lu.%lu", calc/1000, calc%1000);

Output: 3187.555.

Now of course you will lose a bit of accuracy during each division since the calculation is capped at 3 decimals in this example. And the end result is truncated, not rounded. If accuracy is important, then you could step up to 64 bit arithmetic. This is slower on a 32 bit MCU but it is still far faster than software floating point. And as it turns out, probably more accurate too:

uint64_t calc = 10000000000ull; // 10 decimals
    calc *= 150;
    calc *= 10000;
    calc /= 155;
    calc *= 100;
    calc /= 138;
    calc *= 100;
    calc /= 220;
printf("%llu.%llu", calc/10000000000ull, calc%10000000000ull);

Output: 3187.5557822261