O básico que todo mundo aprende, mas raramente entende direito
Um número natural é par quando ele é divisível por 2 sem sobrar nada. Pronto. A definição formal diz que n é par se existe um inteiro k tal que n = 2k. O que isso significa na prática é simples: você divide por 2 e o resto é zero. 2, 4, 6, 8, 10 — todos pares. 1, 3, 5, 7, 9 — todos ímpares. O que muita gente esquece é que o zero também é natural e também é par. 0 = 2 × 0. Não tem mágica. Muitos professores pulam essa parte e os alunos ficam confusos na hora de programar ou provar algo mais avançado. Eu já vi gente jurar que zero é ímpar porque "não parece". Números não têm aparência. Eles têm propriedades.
Quando o número natural é par — e como verificar na prática
A forma mais direta de verificar se um número natural é par é usar o operador módulo. Em praticamente qualquer linguagem de programação, você escreve algo como num % 2 == 0. Se retornar verdadeiro, o número é par. Isso vale para qualquer natural que o sistema consiga representar. Em Python, em C, em JavaScript, em SQL — o operador % retorna o resto da divisão inteira. Pra quem não programa e quer fazer na mão: olhe o último dígito. Se for 0, 2, 4, 6 ou 8, o número é par. Funciona porque o sistema numérico é decimal. O 10 é par, então qualquer potência de 10 é par, e o resto da divisão depende exclusivamente do último dígito. 347.826 termina em 6, logo é par. 1.000.003 termina em 3, logo é ímpar. Você não precisa dividir nada.
Um detalhe que as pessoas ignoram: essa regra do último dígito funciona em qualquer base par. Em binário, por exemplo, um número é par se e só se terminar em 0. É por isso que verificação de paridade é tão barata em hardware — basta olhar um bit. Eu tive um problema real com isso há alguns anos. Estava validando dados brutos de um sistema legado que gerava IDs como strings, não como números inteiros. Um dos campos vinha como "0042" e meu código simplesmente fazia int(valor) % 2. Funcionava, mas em outro campo o valor vinha como "00000000000000000000000000000001" — um zero à esquerda em excesso que causava comportamento estranho em Python 2, que interpretava como octal. A solução foi converter explicitamente com base 10: int(valor, 10) % 2 == 0. Perdi duas horas rastreando esse bug porque ninguém documentou que os IDs podiam ter zeros à esquerda.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Outro ponto que causa confusão constante: a definição de números naturais. Alguns autores definem ℕ como {1, 2, 3, ...}, outros como {0, 1, 2, 3, ...}. A convenção moderna, adotada pela maioria dos livros de teoria dos números e pela ISO 80000-2, inclui o zero. Se você está trabalhando com alguém que segue a convenção antiga, pode haver divergência sobre se 0 é par ou se sequer é natural. Em contexto matemático rigoroso, sempre deixe claro qual convenção está usando. Em contexto prático, zero é par em qualquer lugar.
Pegadinhas e limitações que ninguém conta
A verificação por módulo funciona perfeitamente para números pequenos, mas em sistemas com aritmética de precisão fixa você pode encontrar edge cases. Em C, por exemplo, operar com números muito grandes pode causar overflow antes mesmo da operação %. Em Python isso não acontece porque os inteiros têm precisão arbitrária, mas em linguagens como C++, Java ou Go você precisa usar tipos como long long ou BigInteger dependendo do escopo. Outro problema comum: números negativos. A pergunta original fala de números naturais, que por definição são não negativos. Mas se você estender a verificação para inteiros negativos, o módulo se comporta de forma diferente entre linguagens. Em Python, -3 % 2 == 1, então a verificação ainda funciona. Em C e Java, -3 % 2 == -1, o que quebra uma verificação ingênua do tipo num % 2 == 0. A correção é usar abs() ou verificar se o resultado é diferente de zero, não igual a zero.
Se você está processando milhares ou milhões de valores, a verificação bitwise num & 1 == 0 é ligeiramente mais rápida que num % 2 == 0 em algumas linguagens, porque a divisão é uma operação mais cara que a operação bitwise. A diferença é da ordem de nanosegundos por operação, então só importa em loops extremamente apertados ou em embedded systems com recursos limitados. Para a maioria dos usos, não faz diferença prática. O que a verificação de paridade não faz bem é lidar com floats. Se você recebe um valor como 4.0 e passa por float % 2, o resultado pode ser impreciso por causa da representação binária de ponto flutuante. Sempre converts para int antes, ou use round() para garantir que não há erro de precisão mascarado. Eu já vi um script de auditoria falhar silenciosamente por causa disso — números que pareciam pares mas na verdade eram 3.9999999999999996 por causa de operações anteriores.
Se você precisa de uma verificação mais robusta do que % 2 em contextos financeiros ou de validação crítica, considere usar bibliotecas de aritmética decimal em vez de float. O módulo Decimal do Python, por exemplo, preserva precisão exata e evita esses erros de arredondamento.
