Para exemplificar este problema (bug?) compile e execute o seguinte programa em C:


Ao compilar e executar este código, misteriosamente a resposta 339 é impressa!

O mesmo não ocorre em outras linguagens, como PHP por exemplo, que imprime corretamente 340:


Ou, direto na linha de comando:

$ php -r '$a=200; $a = (int)($a*0.7); printf ("a=%d\n", $a);'

Sendo que usei (int) para garantir que a seja do tipo int, como no C, e usei o printf para ser como no C, igual.

Parece que estamos diante de um estranho bug de compilador C, que não existe no interpretador do PHP. Ou não?

Pois matematicamente esta operação resulta em 340 e não existe margem para demais interpretações, pois 0,7 multiplicado por 200 resulta em 140 e de forma exata, sem casas decimais. 140 somado a 200, por sua vez, resulta em 340.

[1] Comentário enviado por tenchi em 20/03/2008 - 16:14h:

Mais um sensacional Artigo do Prof. Elgio. Vai pros favoritos pra eu nunca mais esquecer! ;-)

[2] Comentário enviado por jmsandy em 20/03/2008 - 17:16h:

Opa, blza?

Este episódio não acontece somente com este produto. Pegando o seu exemplo 200 x 0.7, o fator 0.7, quase todos os seus múltiplos o valor é arredondado para 1 a menos.
Achei bastante interessante e testei aqui no trabalho em um compilador for Windows quando chegar em casa vou testar no Linux para tirar a tema. Mais observação muito interessante. Em determinados compiladores, como o dá Borland, existe um erro quanto a ponto flutuante que voce tem que declarar um prototipo de uma função para ele não acontecer. E támbém o flush(stdin) para limpar o buffer(ou alguma coisa parecida é que não me recordo muito bem).
Está de parabéns pela observação.

José Mauro Sandy

[3] Comentário enviado por antonioclj em 20/03/2008 - 17:47h:

Mas isto vai acontecer mesmo. Você declarou um inteiro e faz uma multiplicação com ponto flutuante, vai dar inteiro na resposta. Você tem que usar o modificador float e não int. Bom isto é para os porgramadores de plantão.

[4] Comentário enviado por elgio em 20/03/2008 - 17:51h:

Oi Antonio.

Sabemos disto.
Mas acho que tu não entendeu direito o FOCO que eu explorei.

No caso a multiplicacao 0.7*200 devia resultar em um inteiro redondo, assim como 0.6 * 100 que resulta em 60.

Não tem poblema algum misturar int com doubles ou float em C, desde que VOCÊ SAIBA o que está fazendo. Eu uso muito isto (mesmo que raramente saiba o que estou fazendo :-D)

[]'s

[5] Comentário enviado por f_Candido em 20/03/2008 - 18:55h:

Simplesmente Perfeito.

[6] Comentário enviado por gabrield em 20/03/2008 - 22:18h:

Alta qualidade!!!

Parabéns cara pelo artigo!

[7] Comentário enviado por countercraft em 21/03/2008 - 00:42h:

Não sei programar em C, mas fiquei curioso e compilei o código acima no GCC e ele retornou 340 mesmo :)

[8] Comentário enviado por pedroarthur.jedi em 21/03/2008 - 09:39h:

Você já leu algo acerca de erros de representação?
Qualquer livro de calculo numérico tem...

[9] Comentário enviado por rui_alex em 21/03/2008 - 11:03h:

Ta bom ta.

[10] Comentário enviado por elgio em 21/03/2008 - 11:44h:

Gabriel!.

Em arquiteturas 64 bits este erro não ocorre.
Não sei exatamente PORQUE NÃO OCORRE, pois testei em um servidor 64 bits que tenho acesso e vi que os arredondamentos SÃO FEITOS!!

Inclusive COM MESMA versão de GCC.

Meu notebook, 32 bits, GCC 4.1.2.
Tamanho de um double: 8 bytes
0.7 = 0.6999999999999999555910790149937383830547

Em um servidor 64 bits, GCC 4.1.2
Tamanho de um double: 8 bytes
0.7 = 0.6999999999999999555910790149937383830547

Mas no 64 bits o GCC informa CORRETAMENTE 340 como tu falou!

Se alguém sabe o motivo, poderia contribuir. Este GCC para 64 bits é o PRIMEIRO COMPILADOR C que faz o cálculo CORRETO! O Dev++, Borland e GCC 32 bits fazem errado.

[11] Comentário enviado por elgio em 21/03/2008 - 11:45h:

pedroarthur.jedi: sim, eu conheço bem os erros de representação.

Tanto que no artigo eu descrevo isto como um erro.
O que ocorreu neste caso NÃO É UM MISTÉRIO. Só escrevi o artigo para que todos que programem em C tenham muito cuidado com estes erros.

[12] Comentário enviado por countercraft em 21/03/2008 - 16:00h:

Realmente, fiz este teste no Arch 64, com GCC 4.2.3.

[13] Comentário enviado por rui_alex em 21/03/2008 - 18:22h:

[There was strong agreement in the C89 Committee that floating values should truncate toward zero when converted to an integer type, the specification adopted in the Standard.]

[Many results are exact or correctly rounded when computed with twice the number of digits of
precision as the data.]
-c99 Rationale-

Na arquitectura 64 bits suponho que os floats sejam pelo menos 8 bytes?

[14] Comentário enviado por elgio em 21/03/2008 - 20:30h:

Bom...

O que eu descobri com um sizeof foi:

32 bits: int, long int e float em 32 bits. double em 64 bits, "long double" com 12 bytes (96 bits). Mas isto o que o gcc retorna, não quer dizer que seja o que a ULA e o co-processador suporta (alguém bom em Hardware ai?)

No 64 bits, MESMA VERSÃO de gcc, obtive: int e float em 32 bits, double em 64 bits e "long double" com 16 bytes (128 bits).

Mas é estranho, pois em ambas o problema de PRECISÃO EXISTE, isto é, 0.7 não é representável com PRECISÃO.

Por que diabos o gcc para 64 bits realiza algum ARREDONDAMENTO?

[15] Comentário enviado por removido em 22/03/2008 - 10:34h:

interessante,
quem sabe faz ao vivo !!!!!!!!!!

[16] Comentário enviado por luizpetiz em 22/03/2008 - 14:45h:

É... legalzinho!
Psiu! Tô falando assim porque o cara é meu professor na ulbra. Não posso dizer que é um baita artigo e só um cara como ele poderia dedicar-se a esses assuntos e tal.., que ele é fera mesmo, se não ele se convence...

[17] Comentário enviado por GilsonDeElt em 22/03/2008 - 19:43h:

legal esse trem!

ainda tô começando na programação, e num sabia dessa...

[18] Comentário enviado por estevao_90 em 22/03/2008 - 21:01h:

mt bom...
meu professor sempre alerta a gente quando a esse mistério do C
o negócio é: se for precisar de ponto flutuante, coloca todas variáveis envolvidas como float, por exemplo, facilita a vida! rsrs

[19] Comentário enviado por Bruno-Sam em 22/03/2008 - 22:21h:

tá uma coisa a se levar em conta na hora de escolher a representação numérica. parabéns pelo artigo.

[20] Comentário enviado por paulloal em 26/03/2008 - 11:31h:

tudo cupa da IEEE hUIAIuhA..
mto bom artigo..

[21] Comentário enviado por anonimo1234 em 29/03/2008 - 23:44h:

Interessante,um bom exemplo da importancia da definição de tipos,pois o tipo apropriado para essa operação creio que seja float e não int,para não ficarmos sujeitos a arrendodamentos imperfeitos do C.

[22] Comentário enviado por Sam L. em 04/12/2008 - 23:21h:

Eu executei o script e ocorreu o mesmo erro, 'a=339'
Mas consegui evitar isso fazendo assim:

#include <stdio.h>
int main()
{
int a;
a = 200;
a = (a *7)/10 + a;//ou a = (a*7/10) + a; ao inves de '(a*0.7)'
printf("O valor de a eh %d\n", a);
return 0;
}

e obtive o resultado correto:
'O valor de a eh 340'