Numero Racional Nao Inteiro

Entendendo o que são números racionais não inteiros na prática

A gente costuma confundir porque todo número decimal parece racional, mas nem todo número racional dá decimal exato ou periódico simples quando você faz a divisão. Número racional não inteiro é basicamente qualquer fração onde o numerador não é múltiplo do denominador. Ponto. O problema é que a teoria ensina isso de forma muito limpa e a prática mostra que a borda disso é bem mais suja do que parece. É um número que pode ser escrito na forma a/b, onde a e b são inteiros e b diferente de zero, mas o resultado da divisão não é um número inteiro. Então 3/4, 7/2, -5/3 entram nessa categoria. O que as pessoas não entendem direito é que 0,333... repetindo é a mesma coisa que 1/3, e que existem infinitos racionais não inteiros entre qualquer dois inteiros, não importa quão perto eles estejam. Isso parece óbvio no papel, mas gera confusão na hora de programar ou calcular. No meu trabalho com processamento de dados, tive um problema específico recentemente que ilustra bem onde isso pega. Estava trabalhando com um arquivo CSV que tinha colunas de medições expressas como frações impróprias — coisas como 47/13, 103/7, 256/9. O script que eu usava convertsia tudo para decimal com duas casas decimais usando round() do Python. O resultado era que valores como 1/3 viravam 0,33 e 2/3 viravam 0,67, e quando eu somava as colunas depois, o total dava errado por cerca de 0,003 a 0,008 dependendo dos dados. A solução foi usar o módulo fractions do Python, que guarda o número como numerador e denominador inteiros até o momento final da operação, e só converte para decimal no último passo. Isso cortou o erro de acumulação de praticamente zero para precisão aceitável em menos de dois minutos de ajuste.

Como trabalhar com eles sem errar

A regra básica é sempre manter a forma fracionária o máximo de tempo possível antes de converter para decimal. Isso vale tanto para planilhas quanto para código. Se você está montando uma conta com várias etapas, cada conversão intermediária para decimal introduz um erro de arredondamento que se propaga. Comece com as frações, simplifique quando fizer sentido, e só vire decimal na última etapa. Um detalhe que muita gente não considera: números racionais não inteiros podem ter representação decimal periódica pura ou mista, e distinguir os dois casos ajuda a escolher a abordagem certa. Se o denominador, depois de simplificado, tem apenas os fatores primos 2 e 5, a dízima é finita. Se tiver qualquer outro fator primo, é periódica. Por exemplo, 5/8 tem denominador 2³, então a divisão é exata: 0,625. Já 2/7 tem denominador 7, que não é 2 nem 5, então gera 0,285714... repetindo. Saber isso de antemão evita que você gaste tempo tentando encontrar um padrão de repetição que não existe. Outra coisa que os livros não enfatizam bastante é a questão da simplificação antes de operar. Frações como 450/750 parecem diferentes de 3/5, mas são o mesmo número racional. Se você não simplificar, vai acabar fazendo cálculos desnecessariamente complicados e aumentando a chance de erro. Eu costumo dividir numerador e denominador pelo MDC antes de qualquer coisa. Em código, isso é uma linha com math.gcd. Em planilha, você pode fazer uma coluna auxiliar com essa simplificação automática.

Pegadinhas comuns que ninguém avisa

A primeira é confundir número racional com número decimal. Todo racional não inteiro é decimal, mas nem todo decimal é racional. Pi não é racional. Raiz quadrada de 2 também não. A diferença prática aparece quando você precisa representar o número com precisão infinita: racionais permitem isso com frações, irracionais não. A segunda pegadinha é mais técnica e acontece muito em contextos de engenharia e finanças. Quando você opera com racionais muito próximos entre si, como 1/3000 e 1/3001, a subtração gera um resultado com denominador enorme. Se depois você converter para decimal com poucas casas, o erro relativo pode ser grande mesmo que o erro absoluto pareça pequeno. Eu vi isso acontecer em um cálculo de tolerância mecânica onde duas peças tinham espessuras de 1/3000 metro e 1/3001 metro, e a diferença foi truncada para zero em uma etapa intermediária, fazendo com que todo o restante do cálculo saísse errado. A correção foi manter a fração até o fim. Existe ainda um problema de representabilidade em sistemas computacionais. floats de ponto flutuante usam base 2, e frações como 1/10 não têm representação exata nesse formato. Isso significa que 0.1 + 0.2 em Python não dá exatamente 0.3. O erro é da ordem de 10^-16, mas em cálculos financeiros ou científicos sensíveis isso importa. A solução padrão é usar Decimal do Python com precisão configurável, ou fractions, dependendo do caso.

Limitações que precisam ser ditas

Trabalhar com frações exatas tem um custo. A simplificação e a arithmetic com denominadores grandes ficam lentas conforme o número de operandos cresce. Para uma dezena de operações, não é problema. Para milhares de linhas de dados, pode ser. Nesse cenário, frações exatas podem ser 10 a 50 vezes mais lentas que operações com floats, dependendo do tamanho dos numeradores e denominadores. Se você está lidando com dados massivos onde a precisão absoluta não é crítica, floats com precisão dupla geralmente são suficiente e muito mais rápidos. O ideal é usar frações apenas nas etapas que exigem exatidão e converter para decimal ou float nas demais. Não adianta forçar representaçãofracionária em tudo só porque é teórica-mente mais bonito. Também vale mencionar que existem casos onde não faz sentido usar racional não inteiro. Medidas experimentais com incerteza intrínseca, como temperatura lida com sensor ou peso bruto de produto, já carregam erro de medição. Representar isso como fração exata dá uma falsa impressão de precisão. Nesses casos, intervalos de confiança ou notação com algarismos significativos são mais honestos.