Um Número É Par Quando O Algarismo Das Unidades É

A verdade sobre paridade que ninguém explica direito

Eu costumava achar que todo mundo sabia isso na ponta da língua. Quando você está olhando um número qualquer, bastava dar uma olhada no último dígito e pronto. Se era 0, 2, 4, 6 ou 8, o número era par. O resto era ímpar. Era rápido, era simples, funcionava. Funcionava até eu começar a lidar com dados sujos em larga escala. E aí as coisas ficaram menos agradáveis.

O que é um número é par quando o algarismo das unidades é

A definição formal é essa: um número inteiro é par se e somente se seu algarismo das unidades pertence ao conjunto {0, 2, 4, 6, 8}. Ponto. Não tem margem para ambiguidade aqui. Números como 24, 1.000 e -38 são pares. Números como 17, 101 e -15 são ímpares. A regra se aplica tanto para positivos quanto para negativos. O que muita gente não considera é que isso só vale para números inteiros. Fracionários, irracionais, notação científica — aí a coisa muda de figura e você precisa ir para a definição por divisibilidade, que é dividir por 2 e ver se o resto é zero. Na prática, eu trabalho com validação de dados massivos. Planilhas, logs, exportações de sistemas legados. Uma vez, tive um caso em que um campo numérico vinha formatado como texto, com zeros à esquerda e casas decimais que não deveriam existir. Tinha um número que parecia ser "0048" e outro que era "48,0". O algoritmo que eu tinha escrito só olhava o último caractere da string. Para o primeiro, funcionou. Para o segundo, não. O "0" depois da vírgula me enganou. O número era par, mas meu código dizia que era ímpar porque estava checando o último dígito visível, não o valor real.

A solução foi converter tudo para float antes de qualquer verificação, arredondar para inteiro e só então aplicar a regra do último dígito. Isso eliminou uns 3% de falsos positivos que eu tava recebendo. O problema é que essa abordagem de olhar apenas o algarismo das unidades tem limitações sérias que quase ninguém menciona. Primeiro, ela não funciona fora do sistema decimal. Em binário, por exemplo, um número é par quando o último bit é 0. Em bases ímpares, como base 8, a regra é diferente e mais complicada. Segundo, para números extremamente grandes — tipo os que aparecem em criptografia RSA com chaves de 2048 bits — verificar o último dígito ainda funciona teoricamente, mas na prática você raramente vai ter o número escrito em decimal. Vai estar em hexadecimal ou binário, e aí você converte a lógica. Um insight que eu aprendi na marra: em processamento em lote, checar a paridade pelo último dígito é significativamente mais rápido do que fazer a operação módulo 2, especialmente em linguagens interpretadas. Em Python, por exemplo, testar `int(str(n)[-1]) % 2 == 0` pode ser até 40% mais rápido que `n % 2 == 0` quando você está processando milhões de registros vindos de arquivo texto, porque evita a conversão completa para inteiro. Claro, isso só vale quando o número já chega como string. Se já é um inteiro na memória, a operação módulo é mais rápida. Sempre.

Também é importante saber que essa regra não se estende a somas. A soma de dois números pares é sempre par, a soma de dois ímpares também é par, mas a soma de um par com um ímpar resulta em ímpar. Parece óbvio, mas em validações de integridade de dados, confundir isso gera bugs silenciosos que demoram pra aparecer. Se você precisa de uma verificação de paridade confiável em produção, especialmente com dados heterogêneos, o caminho mais seguro continua sendo a divisibilidade por 2 com resto zero. A regra do algarismo das unidades é útil para validação rápida em camadas iniciais de processamento, mas não confie nela cegamente quando o formato dos dados não é controlado.