Cuidado com números em Ponto Flutuante
Quanto seria (200*0,7) + 200? 340 você diria? Então você deve ler este artigo. Dependendo da situação esta operação matemática não resultará em 340. Absurdo? Quem programa em linguagem de programação C deve ficar atento!
[ Hits: 125.167 ]
Por: Elgio Schlemer em 20/03/2008 | Blog: https://profelgio.duckdns.org/~elgio
Entendendo conversões implícitas em C
O C é uma linguagem compilada que aceita que o programador tenha certas liberdades. Ele dificilmente critica (com erro de compilação) alguma atribuição que se faça, mesmo que envolva tipos de dados completamente diferentes. Permite que inteiros sejam atribuídos para char, doubles para inteiros e assim por diante.
Sempre que uma mesma operação matemática envolver tipos de dados diferentes, o C realizará uma conversão implícita de dados, ou seja, um ou mais dados serão convertidos para outro tipo durante a operação. Como exemplo disto:
No exemplo acima o valor 34.234 não pode ser atribuído ao x, pois x é inteiro e não aceita números com ponto flutuante. O número de ponto flutuante 34.234, neste caso, é convertido para int antes da atribuição. A conversão, neste caso, se dá simplesmente eliminando as casas decimais sendo que x receberá apenas 34.
Agora um exemplo mais interessante:
Neste caso tem-se que o tamanho de uma variável char é de um byte (8 bits) e da variável x de 32 bits (considerando um compilador de 32 bits). Em x cabe tranquilamente o valor 1000, mas em c, por ser meros 8 bits, o espaço de valores que cabe é o seguinte:
Mas qual é o valor que c receberá?
Para isto será necessário decompor o valor 1000 em 32 bits:
Logo, qual o valor de c? 232?
Sim e não!
Se a variável c NÃO estiver usando sinal, sim, o valor é 232. Porém se estiver usando sinal (e o Intel usa complemento de 2 para representar números negativos) o valor inteiro interpretado por c (ao imprimir ele com um %d por exemplo) será -24:
Sempre que uma mesma operação matemática envolver tipos de dados diferentes, o C realizará uma conversão implícita de dados, ou seja, um ou mais dados serão convertidos para outro tipo durante a operação. Como exemplo disto:
int x;
x = 34.234;
x = 34.234;
No exemplo acima o valor 34.234 não pode ser atribuído ao x, pois x é inteiro e não aceita números com ponto flutuante. O número de ponto flutuante 34.234, neste caso, é convertido para int antes da atribuição. A conversão, neste caso, se dá simplesmente eliminando as casas decimais sendo que x receberá apenas 34.
Agora um exemplo mais interessante:
int x;
char c;
x = 1000;
c = x;
char c;
x = 1000;
c = x;
Neste caso tem-se que o tamanho de uma variável char é de um byte (8 bits) e da variável x de 32 bits (considerando um compilador de 32 bits). Em x cabe tranquilamente o valor 1000, mas em c, por ser meros 8 bits, o espaço de valores que cabe é o seguinte:
- de 0 até 255 se a variável não estiver considerando sinal
- de -128 a 127 se estiver considerando sinal.
Mas qual é o valor que c receberá?
Para isto será necessário decompor o valor 1000 em 32 bits:
1000 = 00000000 00000000 00000011 11101000
byte +SIG byte -sig
O byte menos significativo de 1000 é 11101000 que se lido separadamente, apenas ele, resulta no decimal 232. Como c tem a possibilidade de apenas um byte, é apenas este byte que é atribuído ao c.
Logo, qual o valor de c? 232?
Sim e não!
Se a variável c NÃO estiver usando sinal, sim, o valor é 232. Porém se estiver usando sinal (e o Intel usa complemento de 2 para representar números negativos) o valor inteiro interpretado por c (ao imprimir ele com um %d por exemplo) será -24:
11101000 => 00010111 (232 complementado) 00010111 + 1 =00011000 (24 em decimal)O compilador C faz o tempo todo conversões implícitas, seja inserindo bytes em 0 (para conversão de char para int SEM sinal), seja inserindo bytes em 1 (para conversão de char para int COM SINAL) ou cortando bytes:
char a;
int x;
a = -2; /* em binário 11111110 */
x = a; /* x deve ter -2, que em binário 32 bits é
11111111 11111111 11111111 11111110
Neste caso o C inseriu três bytes em UM para fazer com que o x tivesse -2.
Se ele inserisse três bytes em ZERO x teria 254 e não -2.
Ele, o C, faria isto se o a fosse declarado como unsigned:
unsigned char a;
*/
Páginas do artigo
1. Pequeno programa em C2. Entendendo conversões implícitas em C
3. Conversão de ponto flutuante para inteiro
4. Nem tudo é representável
5. Conclusão
Outros artigos deste autor
Criptografia assimétrica com o RSA
Iptables protege contra SYN FLOOD?
Fundamentos da criptografia assimétrica
Leitura recomendada
Programação com números inteiros gigantes
Instalando Facebook Folly através do Conan
Acessando a porta paralela via Linux
A duplicação do buffer de saída na chamada de sistema fork() do Linux
Comentários
[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! ;-)
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
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.
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
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
[6] Comentário enviado por gabrield em 20/03/2008 - 22:18h
Alta qualidade!!!
Parabéns cara pelo artigo!
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 :)
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...
Você já leu algo acerca de erros de representação?
Qualquer livro de calculo numérico tem...
[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.
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.
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.
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?
[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?
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 !!!!!!!!!!
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...
É... 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...
legal esse trem!
ainda tô começando na programação, e num sabia dessa...
[18] Comentário enviado por estevao90 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
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 brunojbpereira 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.
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..
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.
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 SamL 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'
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'
[23] Comentário enviado por genilsondasilva em 09/10/2012 - 09:05h
O jeito é evitar misturar int com float. Agora se realmente for necessária essa conversão, devemos usar uma função para arredondamento.
Se o C tiver a função "round()" (ainda não testei), senão podemos criar uma função, por exemplo:
int arredonda(double num)
{
int num_int = num;
if( (num - num_int) >= 0.5)
{
return (num_int +1)
}
else
{
return (num_int)
}
}
Ou então:
#include <math.h>
#define ARRED(x) floor( x + 0.5 ) //Isso retorna um inteiro
#define ARRED2(x, z) floor( x*pow(10, z) + 0.5 )/pow(10, z) //sendo z o numero de casas decimais
Assim que for possível vou testar em casa no linux.
O jeito é evitar misturar int com float. Agora se realmente for necessária essa conversão, devemos usar uma função para arredondamento.
Se o C tiver a função "round()" (ainda não testei), senão podemos criar uma função, por exemplo:
int arredonda(double num)
{
int num_int = num;
if( (num - num_int) >= 0.5)
{
return (num_int +1)
}
else
{
return (num_int)
}
}
Ou então:
#include <math.h>
#define ARRED(x) floor( x + 0.5 ) //Isso retorna um inteiro
#define ARRED2(x, z) floor( x*pow(10, z) + 0.5 )/pow(10, z) //sendo z o numero de casas decimais
Assim que for possível vou testar em casa no linux.
Patrocínio
Site hospedado pelo provedor RedeHost.
Destaques
Artigos
Enviar mensagem ao usuário trabalhando com as opções do php.ini
Meu Fork do Plugin de Integração do CVS para o KDevelop
Compartilhando a tela do Computador no Celular via Deskreen
Como Configurar um Túnel SSH Reverso para Acessar Sua Máquina Local a Partir de uma Máquina Remota
Configuração para desligamento automatizado de Computadores em um Ambiente Comercial
Dicas
Criando uma VPC na AWS via CLI
Multifuncional HP imprime mas não digitaliza
Dica básica para escrever um Artigo.
Como Exibir Imagens Aleatórias no Neofetch para Personalizar seu Terminal
Tópicos
como coloco para instalar com esse erro. (13)
Alguém sabe de documentos de texto e /ou vídeo aulas de certificações ... (1)
Top 10 do mês
-
Xerxes
1° lugar - 69.666 pts -
Fábio Berbert de Paula
2° lugar - 53.023 pts -
Buckminster
3° lugar - 20.065 pts -
Mauricio Ferrari
4° lugar - 16.421 pts -
Alberto Federman Neto.
5° lugar - 15.203 pts -
Daniel Lara Souza
6° lugar - 14.282 pts -
Diego Mendes Rodrigues
7° lugar - 13.947 pts -
edps
8° lugar - 11.922 pts -
Andre (pinduvoz)
9° lugar - 11.719 pts -
Alessandro de Oliveira Faria (A.K.A. CABELO)
10° lugar - 11.268 pts
Scripts
A maior comunidade GNU/Linux da América Latina! Artigos, dicas, tutoriais, fórum, scripts e muito mais. Ideal para quem busca auto-ajuda.
Site hospedado por:
