C: double to int conversion error in gcc 6.3.0

Question

I have the following c program, and some of the times I run it, the output differs, based on the compiler and the platform. I understand that double to int conversion could cause problems.

Here is the code:

//Compiler version gcc 6.3.0
#include <stdio.h>
#include <math.h>

int main(void){
    double d = 2;
    printf("%.20lf\n", pow(10, d));
    printf("%d\n", (int)pow(10, d));
    printf("%d\n", (int)pow(10, 2));
}

100 is the expected value, but the statement

    printf("%d\n", (int)pow(10, d));

has 99 as output when I use both gcc 6.3.0 and Windows 10 x64, but not in other cases.

Here are some results:

//gcc 6.3.0 (Sublime Text 3) in Windows 10 x64
100.00000000000000000000
99 ->this is the problem
100

//gcc 6.3.0 in Android (using Dcoder app)
100.00000000000000000000
100
100

//MSVC(VS 2017 x86) in Windows 10 x64
100.00000000000000000000
100
100

I also tested some online gcc(6.3.0) compilers but all the outputs were 100.

Thanks for the help.

Answer 1

Some implementations of pow return values different from 100 for pow(10, 2). For example, 99.9999999999999857891452847979962825775146484375 may be returned. When this double value is converted to int, the result is 99.

This is a problem in the quality of the pow implementation. Good pow implementations return exact results when exact results are possible.

Additionally, I suspect printf("%.20lf\n", pow(10, d)) is not formatting correctly in the Windows implementation—it may be rounding its conversion internally to something like 15 significant decimal digits before formatting it to 20 digits for output. You can test this by printing printf("%.20g\n", pow(10, d)-100). That will subtract 100 from pow(10, d) in double arithmetic. If it shows a non-zero output, you know that pow(10, d) was not exactly 100, so the printf("%.20lf\n", pow(10, d)) showed an incorrect result.

Note that pow is a difficult function to implement well. Only a limited number of cases have exact results, so most results are necessarily inexact. However, even in those cases, getting a result that is correctly rounded—rounded to the nearest representable value—is difficult. To my knowledge, nobody has implemented pow with that quality. Most pow implementations allow some additional error, and therefore you should not rely on pow to be correctly rounded. However, it is possible to implement pow so that cases where exact results are possible do indeed return exact results, and some implementations achieve that.