Como lidar com operações de multiplicação e divisão na prática
A primeira coisa que todo mundo aprende é a ordem dos operadores: multiplicação e divisão vêm antes de adição e subtração. Mas a parte que raramente explicam direito é como lidar com os casos em que os números simplesmente não dividem direito, e como isso interfere em tudo ao redor. Eu passei horas debugando um script de cálculo financeiro porque alguém tinha colocado uma divisão inteira dentro de uma expressão grande sem parênteses, e o resultado ia para o lugar errado por causa da associatividade. O programa não errava por ignorância, só porque a precedência dos operadores foi aplicada de forma diferente do que o autor esperava.
Entendendo operações de multiplicação e divisão
Multiplicação é soma repetida. Divisão é a operação inversa. Parece bobo dizer isso, mas é exatamente o que precisa estar claro na cabeça antes de avançar. Quando você faz 7 × 3, está somando 7 três vezes. Quando faz 21 ÷ 3, está perguntando quantas vezes o 3 cabe no 21. A resposta é 7. Se sobrar resto, aí a coisa muda de figura. O que as pessoas esquecem é que divisão por zero não tem solução. Não é um número especial, não é infinito no sentido prático. É indefinido. E em programação, dependendo da linguagem e do tipo de dado, isso pode gerar uma exceção, um valor infinito (inf), ou NaN. Eu já vi planilhas inteiras travarem porque uma célula vazia estava sendo usada como divisor. O Excel mostra #DIV/0! e para por aí. Nada de mágica.
A associatividade também é um ponto cego. Multiplicação e divisão são associativas à esquerda na maioria das linguagens e calculadoras. Isso significa que a ÷ b ÷ c é calculado como (a ÷ b) ÷ c, e não como a ÷ (b ÷ c). A diferença é enorme. Pegue 100 ÷ 10 ÷ 2. Da esquerda para a direita dá 5. Da direita para a esquerda daria 20. Se você escreveu a expressão achando que era a segunda forma, o resultado vai estar errado e pode demorar para perceber porque nada dispara erro. Um detalhe que todo mundo perde: divisão inteira versus divisão de ponto flutuante. Em Python, 7 // 3 retorna 2. Em Python, 7 / 3 retorna 2.333... Em C, se ambos os operandos são inteiros, 7 / 3 também retorna 2. A queda é que muitos assumem que o compilador ou interpretador vai fazer a divisão decimal automaticamente. Não faz. Se um dos operandos for float, o resultado será float. Se ambos forem int, o resultado será int em muitas linguagens. Isso mata gente. Literalmente, em cálculos financeiros onde o arredondamento errado acumula e vira diferença de centavos que vira diferença de reais no final do mês.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Outro ponto: representação decimal. 1/3 não tem representação exata em ponto flutuante binário. O mesmo vale para 0.1. Eu once perdi quase um dia inteiro caçando um bug em que duas contas que deveriam ser idênticas apresentavam diferença de 0.000000000000001. A causa? Sequência diferente de operações de multiplicação e divisão com floats. O problema não era do algoritmo em si, era da ordem em que os cálculos eram executados. Reorganizar a expressão resolveu. Quando se trata de operações grandes, a régua prática é simples. Se você está multiplicando números com muitos dígitos manualmente, a técnica de decomposição em potências de 10 funciona bem. Multiplicar 347 por 56, por exemplo, vira (300 × 50) + (300 × 6) + (47 × 50) + (47 × 6). Cada parte é mais simples. A divisão longa funciona no mesmo princípio, só que ao contrário: você vai retirando pedaços do dividendo e subtraindo múltiplos do divisor.
O que eu recomendo sem rodeio é sempre verificar a unidade de medida antes de operar. Multiplicar metros por metros gera metros quadrados. Multiplicar metros por segundos não gera nada útil na maioria dos contextos. Se você está calculando velocidade, é distância dividida por tempo, não o contrário. Já vi relatório de engenharia com unidade errada porque alguém multiplicou o que deveria dividir, e o número estava "correto" numericamente mas semanticamente absurdo. A validação de unidades economiza muito retrabalho. Se você está implementando isso em código, evite divisões encadeadas sem parênteses explícitos. Use parênteses. Não confie na memória de qual é a regra de precedência. E se estiver lidando com dinheiro, use tipos decimais ou trabalhe sempre com centavos como inteiros. Float é traiçoeiro para valores monetários.
Em resumo,.operations de multiplicação e divisão parecem triviais até o momento em que o cenário fica complexo. Aí a diferença entre saber a regra e entender como ela se aplica no mundo real é o que separa quem perde tarde da noite com bugs difíceis de achar de quem já previu o problema antes de escrever a primeira linha.
