Bug in gcc?

[diegotorquemada]

Hello,

Probably this is not the right place to ask, but anyway I will post my question.

Why does this code:

#include <stdio.h>

int main(void)
{
int i = 16777217;
float f = 16777217.0;
printf("El entero es: %d\n", i);
printf("El real es: %f\n", f);
printf("Son iguales: %d\n", i == f);

return 0;
}

Returns the following result?

diego@earendil:~/programas$ gcc -Wall -o prog prog.c
diego@earendil:~/programas$ ./prog
El entero es: 16777217
El real es: 16777216.000000 *** IT IS NOT 16777217.0 !!!!***
Son iguales: 0
diego@earendil:~/programas$

My gcc version:
diego@earendil:~/programas$ gcc --version
gcc (Debian 4.3.2-1.1) 4.3.2

Regards,

Diego Andr?s

 

[Angel]

Hello,

Probably this is not the right place to ask, but anyway I will
post my question.

Why does this code:

#include <stdio.h>

int main(void)
{
int i = 16777217;
float f = 16777217.0;
printf("El entero es: %d\n", i);
printf("El real es: %f\n", f);
printf("Son iguales: %d\n", i == f);

return 0;
}

Returns the following result?

diego@earendil:~/programas$ gcc -Wall -o prog prog.c
diego@earendil:~/programas$ ./prog
El entero es: 16777217
El real es: 16777216.000000
*** IT IS NOT 16777217.0 !!!! ***

Floating point numbers have limited precision. To quote Wikipedia:
"In computing, floating point describes a method of representing an
approximation to real numbers in a way that can support a wide range of
values. The numbers are, in general, represented approximately to a
fixed number of significant digits (the mantissa) and scaled using an
exponent." (Note the word 'approximately'.)

You may get better results by using a double which has higher precision,
but you should never count on floating point numbers to have an exact
value, because they don't. In that respect, you should never use the ==
operator on floating point numbers. You have now seen why not.

See also section 14 of the C FAQ, especially question 14.1.
http://c-faq.com/fp/printfprec.html

 

[James Kuyper]

Hello,

Probably this is not the right place to ask, but anyway I will post my question.

Why does this code:

#include <stdio.h>

Add

int main(void)
{
int i = 16777217;
float f = 16777217.0;
printf("El entero es: %d\n", i);
printf("El real es: %f\n", f);

Add
printf("El espaciamiento de los valores representables es: %f\n",
f*FLT_EPSILON);

printf("Son iguales: %d\n", i == f);

return 0;
}

Returns the following result?

diego@earendil:~/programas$ gcc -Wall -o prog prog.c
diego@earendil:~/programas$ ./prog
El entero es: 16777217
El real es: 16777216.000000 *** IT IS NOT 16777217.0 !!!! ***
Son iguales: 0

The fundamental problem is that it takes 25 bits to represent the value
of 16777217. Your system is probably using IEEE single precision
floating point, which only reserves 23+1 bits for the significand (the
+1 indicates that a neat trick has been used so that one bit doesn't
actually have to be stored). Regardless of whether your system used IEEE
formats or some other format, the macro FLT_EPSILON expands to the
difference between 1.0 and the first representable number after 1.0; it
is directly connected to that number of bits. The net result is that
float on your system doesn't have enough precision to store 16777217
exactly. It can store 16777216 and 16777218, but nothing in-between.

You need to read the article "What every Computer Scientist Should know
about Floating-Point arithmetic". You can find copies of it in many
places on the internet. The first decent one I found in a Google search was
<https://ece.uwaterloo.ca/~dwharder/NumericalAnalysis/02Numerics/Double/paper.pdf>.

 

[Noob]

You need to read the article "What every Computer Scientist Should know
about Floating-Point arithmetic". You can find copies of it in many
places on the internet. The first decent one I found in a Google search was
<https://ece.uwaterloo.ca/~dwharder/NumericalAnalysis/02Numerics/Double/paper.pdf>.

Were you looking /specifically/ for the PDF version?

Or are Oracle's servers (the first hit in the search)
not a decent place on the internet? ;-)

Regards.

 

[James Kuyper]

Were you looking /specifically/ for the PDF version?
Yes.

Or are Oracle's servers (the first hit in the search)
not a decent place on the internet? ;-)

I also wanted an academic or government site rather than a commercial
one. It was all pretty arbitrary - there's lots of copies floating
around the Internet, choose the source you like best. It shouldn't
matter which one you look at.

If it does matter - that's something to be worried about. Could you
imagine someone trying to sabotage the IT industry by flooding the
Internet with copies that have been edited to give subtly incorrect
advice? No? Neither can I. A parody version seems more plausible, but
still unlikely.

 

[Ivan Shmakov]

[...]

Or are Oracle's servers (the first hit in the search) not a decent
place on the Internet? ;-)

I also wanted an academic or government site rather than a commercial
one. It was all pretty arbitrary - there's lots of copies floating
around the Internet, choose the source you like best. It shouldn't
matter which one you look at.

Somehow, and for certain search terms, the S/N ratio appears to
improve greatly once "-site:com" is added to the search terms.

If it does matter - that's something to be worried about. Could you
imagine someone trying to sabotage the IT industry by flooding the
Internet with copies that have been edited to give subtly incorrect
advice? No? Neither can I. A parody version seems more plausible,
but still unlikely.

... And for those truly paranoid, there's a sheer variety of
text comparison tools to choose from.