Usamos cookies para medir audiência e melhorar sua experiência. Você pode aceitar ou recusar a qualquer momento. Veja sobre o iMasters.
No mundo da programação, lidar com números de ponto flutuante sempre traz surpresas. Recentemente, me deparei com um comportamento estranho do Python ao usar a função round em números que parecem simples, mas entregam resultados diferentes dependendo do contexto.
Por exemplo, ao usar round(12.675, 2), o resultado esperado seria 12.68, certo? Mas o Python às vezes mostra 12.67. Isso acontece por causa das limitações de precisão dos números de ponto flutuante e como eles são representados na memória. A decisão fica mais saudável quando o time consegue medir o impacto depois.
Na prática, quando você imprime o valor com alta precisão, percebe que há uma diferença minúscula na representação interna, que acaba influenciando o resultado da função round.
Para quem trabalha com cálculos financeiros, essa questão é ainda mais crítica. É importante entender que o comportamento do round não é uma falha do Python, mas uma consequência do padrão IEEE 754. O valor aparece melhor quando operação, produto e engenharia olham para o mesmo risco. Por isso, o recorte precisa considerar manutenção, validação e caminho de volta. Esse contexto ajuda a separar ganho real de novidade difícil de sustentar.
Quem já passou por isso na rotina? Como vocês lidam com esse tipo de imprecisão, especialmente em projetos que exigem alta precisão? Por isso, o recorte precisa considerar manutenção, validação e caminho de volta. Esse contexto ajuda a separar ganho real de novidade difícil de sustentar. A decisão fica mais saudável quando o time consegue medir o impacto depois. Sem esse critério, a solução pode parecer simples no começo e cara no suporte. O valor aparece melhor quando operação, produto e engenharia olham para o mesmo risco.
A dica que fica é usar bibliotecas específicas como decimal, que oferecem maior controle sobre a precisão e o arredondamento, além de evitar surpresas na hora de apresentar resultados finais. Esse contexto ajuda a separar ganho real de novidade difícil de sustentar. A decisão fica mais saudável quando o time consegue medir o impacto depois. Sem esse critério, a solução pode parecer simples no começo e cara no suporte. O valor aparece melhor quando operação, produto e engenharia olham para o mesmo risco. Por isso, o recorte precisa considerar manutenção, validação e caminho de volta.
Eu já dei de cara com isso na hora de gerar relatórios de cobrança. Acabei criando uma função que força o arredondamento com decimal antes de exibir, ajuda bastante.
No meu time, sempre recomendam o uso do decimal quando a precisão é prioridade. O que atrapalha às vezes é o desempenho, mas pra cálculos críticos, ajuda bastante.
Exato, Larissa. Aqui, a gente também usa decimal pra evitar esses bugs de arredondamento em relatórios financeiros. Mas também é bom deixar claro pras equipes que o desempenho pode cair.
Acho que essa questão de precisão sempre vai ser um tradeoff. Se for pra algo bem crítico, usar decimal é o caminho mesmo. O resto, o float ainda serve bem.