Usei 0.0048, spank me.
Isso querias tu, ah ah
!!...
Isto do cálculo numérico é muito interessante. Os erros ocorrem essencialmente sempre na divisão, por isso é a operação que temos que deixar para fim, repara no cálculo que fiz, deixei a divisão para o final (
1023 * 2.2 / 5). Há outra técnica na divisão inteira que já mencionei por aqui várias vezes e que é super importante, que é adicionar metade do divisor ao dividendo (para números positivos). Isto é fazer um arredondamento ao número inteiro
mais próximo, e o impacto disto "vê-se", não passa despercebido. Portanto ao fazer
a / b em que ambos são inteiros e a divisão é inteira, o que há a fazer é
(a + b/2) / b. A
divisão inteira (operador
div) que os microprocessadores fazem é uma divisão com arredondamento por defeito (deita fora a parte real do resultado), só que para minimizar o erro queremos divisões com arredondamento para o inteiro mais próximo.
O erro vê-se bem neste exemplo:
7 div 4 = 1 mas na verdade
7.0 / 4 = 1.75 portanto a resposta que se quer é
2, o inteiro mais próximo do resultado
1.75. Ao fazermos
(7 + 4 div 2) div 4 = (7 + 2) div 4 = 9 div 4 = 2 que é o inteiro mais próximo do resultado real.
A 1ª vez que esbarrei com isto foi num programa que fiz para rodar uns objectos em 3D. Os vértices são pontos 3D que são rodados, e fiz os cálculos todos em ponto fixo. No entanto, o objecto parecia que se deformava ligeiramente ao rodar, os vértices sofriam de um jitter de 1 pixel, que era bem visível. Depois de analisar bem a coisa percebi que se devia aos arredondamentos por defeito que a divisão inteira dos micros faz, quando estava a mapear os pontos de 3D para 2D para mostrar no ecran. Comecei a fazer como indiquei acima e tudo ficou perfeito,
silky-smooth. O arredondamento por defeito cria artefactos no que quer que seja que se esteja a usar, artefactos de imagem em grafismos, artefactos sonoros ao processar som, etc etc.