Re: [Mingw-users] Unexpected inaccuracy in double to int conversion

[Martin W. <mai...@ma...>]

K. Frank wrote:
> Hello Martin!
>
> On Sat, Aug 4, 2012 at 6:21 PM, Martin Whitaker
> <mai...@ma...> wrote:
>> After updating to the latest version of the MinGW GCC (4.7.0), one
>> of my regression tests started failing. I've isolated the problem
>> to the following test case:
>>
>> #include <stdio.h>
>> #include <math.h>
>>
>> volatile double scale = 3.0;
>>
>> int main(int argc, char *argv[])
>> {
>>     printf("%20.20f\n", 123000.0 / pow(10.0, scale));
>>     printf("%d\n", (int)(123000.0 / pow(10.0, scale)));
>>     printf("%d\n", (int)(123000.0 / pow(10.0, 3.0)));
>> }
>>
>> The output from this is:
>>
>> 123.00000000000000000000
>> 122
>> 123
>>
>>
>> whereas I would have expected the middle number to also be 123.
>>
>> Is this allowed behaviour, or is it a bug?
>
> I don't claim to know for certain, but I would believe that this
> behavior is allowed by the C standard.  (I assume that you are
> treating this as a C program, and I also believe that this behavior
> would be allowed by the C++ standard.)
>
>> I realise double to int
>> conversion is not necessarily exact,
>
> (I believe that double-to-int is required to be exact if the
> double in question is exactly representable by an int, but
> I don't think that that's the issue here.)
>
I was misled by printing out the intermediate double value
and seeing it was an exact integer value. But as another
user has pointed out, the compiler is generating code that
does the calculations in a higher floating point precision,
so the value being converted to an int is not necessarily
the same as the value printed out.

Thanks for the rest of your comments. As you say, Happy
Floating-Point Hacking!

Martin