Por que todo mundo erra na hora da conta
Você já viu alguém somar 0,1 mais 0,2 no computador e aparecer 0,30000000000000004? A maioria das pessoas acha que o computador tá quebrado ou que a calculadora tem defeito. Na verdade, não tem nada disso. O problema é como os números são representados dentro da máquina, e isso acontece desde os anos 1970 quando os microprocessadores foram projetados para trabalhar com ponto flutuante padrão IEEE 754. Quando você entra no campo das operações basicas de matematica, esse comportamento estranho aparece todo dia. A representação binária de frações decimais é simples: 0,1 em binário vira uma dízima periódica, igual a 1/3 em decimal. Não cabe um número infinito de dígitos na memória, então o processador arredonda. Esse arredondamento acumula erro a cada operação. A correção não é mágica, é só ajustar a precisão. No Python, por exemplo, use o módulo decimal com precisão de 28 casas decimais e o resultado volta a ser confiável. No JavaScript, multiplique tudo por 10 elevado à potência necessária, faça a operação inteira e divida de volta. Funciona em 99% dos casos do dia a dia.
Operações basicas de matematica que realmente importam
A adição e subtração parecem triviais até você cruzar casas decimais com potências de dez diferentes. Eu já perdi horas debugando um sistema de cobranças onde a diferença entre R$ 10,50 e R$ 0,10 aparecia como R$ 10,399999999999999. O cliente questionou a fatura, precisei refazer todo o módulo de cálculo e substituir Float por Decimal em toda a codebase. A gambiarra inicial foi multiplicar tudo por 100 antes de operar e dividir depois, mas isso só disfarça o problema em valores menores. O caminho certo é mudar a estrutura de dados. Já a multiplicação e divisão têm seu próprio conjunto de armadilhas. Divisão por zero retorna Inf ou NaN dependendo da linguagem, e em produção isso pode travar um sistema inteiro se não for tratado. Multiplicação de números grandes também gera overflow silencioso em linguagens com tipagem fixa como C e Java. Um int de 32 bits transborda a partir de 2.147.483.647 e vira negativo sem aviso. Use tipos long ou bibliotecas de bigint dependendo do contexto.
Aordenação também merece atenção. Em muitas situações eu vi gente implementar bubble sort para ordenar cinco mil registros achando que ia funcionar porque era um teste simples. Bubble sort é O(n²), então para cinco mil itens você roda milhões de comparações. Quick sort ou o algoritmo nativo da linguagem resolve isso em tempo logarítmico. O Python usa Timsort, que é híbrido e roda bem tanto em dados quase ordenados quanto aleatórios. Confie nele antes de escrever algo do zero.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Erros que vejo todo dia em código novo
O primeiro erro clássico é confiar em == para comparar floats. Isso raramente funciona. Sempre use uma tolerância, um epsilon. Se você quer saber se dois valores numéricos são iguais, compare a diferença absoluta contra um valor pequeno como 1e-9. Isso resolve a maior parte das bruxarias de igualdade. O segundo erro é negligenciar a ordem das operações. Parênteses resolvem, mas muita gente esquece que divisão e multiplicação têm precedência igual e são associativas da esquerda para a direita. 10 / 2 * 5 não é o mesmo que 10 / (2 * 5). O primeiro dá 25, o segundo dá 1. Sem parênteses explícitos, o resultado depende de quem lê e de como a linguagem implementa.
O terceiro erro, e esse é mais sutil, é misturar tipos numéricos sem controle. Inteiro dividido por inteiro em várias linguagens retorna inteiro, cortando a parte decimal. 5 dividido por 2 vira 2 em vez de 2,5. Isso quebra cálculos financeiros, porcentagens, anything que dependa de precisão fracionária. A correção é trivial: converta um dos operandos para float antes de dividir. Mas o problema é que a maioria das pessoas descobre isso só quando o relatório de vendas já saiu errado. Existe ainda o caso dos números muito grandes. Em Python, inteiros têm precisão arbitrária e não estouram como em C. Em outras linguagens, bibliotecas como Bignum ou BigInt existem exatamente para isso. Se o seu domínio envolve criptografia, cálculos astronômicos ou hash codes gigantes, não use int padrão. Vai dar problema.
Quando as operações básicas falham de verdade
Números muito pequenos também causam dor de cabeça. Subtração catastrófica é o nome técnico: quando você subtrai dois valores quase iguais, os dígitos significativos se perdem e o resultado fica dominado pelo ruído de arredondamento. Isso acontece frequentemente em simulações numéricas e algoritmos de física. A solução não é mágica, envolve reformular a equação para evitar a subtração direta ou usar aritmética de precisão estendida. Outro cenário onde tudo despenca é com operações booleanas embarcadas em lógica aritmética. Em linguagens como JavaScript, true vale 1 e false vale 0, então true + false dá 1. Parece útil até você precisar somar something diferente de boleano e o resultado sair completamente errado por coercion automática. Type coercion é um problema real em linguagens dinâmicas.
Para quem precisa fazer cálculos sérios e não quer perder tempo com esses detalhes, a alternativa mais óbvia é usar uma biblioteca especializada. No Python, sympy para álgebra simbólica, numpy para arrays numéricos. No JavaScript, math.js cobre desde operações simples até funções hiperbólicas e matrizes. Para o dia a dia, essas bibliotecas eliminam a maior parte dos problemas que listei aqui. O que eu digo depois de anos vendo gente resolver conta básica da forma errada é: entenda o limite da ferramenta que você está usando. Se você trabalha com dinheiro, use decimal. Se trabalha com ciência, use arrays numéricos com type adequado. Se precisa de precisão exata em frações, vá de rational numbers. O resto é gambiarra que funciona até não funcionar.
