Como listar todos os números primos de forma prática
O básico que ninguém ensina na escola é que, na prática, gerar números primos não é um exercício acadêmico — é uma tarefa operacional que esconde armadilhas dependendo do tamanho que você precisa cobrir. A primeira coisa que me ocorreu quando comecei a lidar com isso foi escrever um gerador ingênuo usando divisões sucessivas. O resultado foi aceitável para alguns milhares, mas rapidamente entrou em colapso quando precisei de faixas maiores, e o tempo de execução triplicava a cada dobro de alcance. Atingir todos os números primos até certo limite exige uma mudança de abordagem antes mesmo de escrever a primeira linha de código.
todos os números primos
Um número primo é aquele que tem exatamente dois divisores distintos: 1 e ele mesmo. O 2 é o único primo par. A partir daí, tudo se resume a testar ou eliminar candidatos, mas o método faz toda a diferença entre um script que termina em segundos e outro que fica rodando enquanto você vai fazer café. O Crivo de Eratóstenes é o ponto de partida razoável para qualquer faixa até algumas centenas de milhões. A ideia é simples: começar com uma lista de candidatos e ir marcando os múltiplos de cada primo encontrado como compostos. O que resta são os primos. Na prática, eu configurei o crivo utilizando um array booleano e otimizei os loops de forma que o incremento dos múltiplos usasse 2*p ao invés de p, já que os múltiplos pares não precisam ser considerados depois de separar o 2. Para faixas entre 10 milhões e 100 milhões, esse ajuste costuma reduzir o tempo em algo perto de 30 a 40 por cento em relação à implementação ingênua, dependendo da linguagem e do hardware. A memória também entra na conta: um crivo para um bilhão ocupa cerca de 125 MB usando bits, mas chega a aproximadamente 1 GB com bytes inteiros, então a escolha da estrutura muda se o ambiente for restrito.
Quando o crivo comum não funciona mais
O crivo de Eratóstenes clássico é rápido, mas ele carrega um gargalo evidente: precisar manter toda a faixa na memória. Isso funciona bem até uns poucos bilhões, mas passa a dar problema quando o objetivo é listar todos os números primos em intervalos grandes como [10^12, 10^12 + 10^7]. Nesse tipo de cenário, a memória tradicional vira o limitador principal, e o que salva é o crivo segmentado. A técnica divide o intervalo em blocos menores, reutiliza os primos base encontrados anteriormente e processa cada segmento de forma independente. A complexidade espacial cai para algo na casa de poucas dezenas de megabytes, enquanto a complexidade temporal permanece próxima da solução completa. Um problema específico que eu enfrentei recentemente envolveu a geração de todos os primos em um intervalo onde o início não era múltiplo de nenhum dos primos pequenos. O código initial marcava posições de forma incorreta porque eu usei a operação módulo diretamente sobre o offset sem ajustar para o primeiro múltiplo válido do primo base. A correção foi usar a função que calcula o primeiro múltiplo maior ou igual ao início do segmento, algo como max(p*p, ((start + p - 1) // p) * p). Esse erro é comum, e ele tende a passar despercebido porque os resultados parecem plausíveis até você fazer uma validação cruzada com uma tabela confiável.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Teste de primalidade para números grandes
Quando o foco muda de listar primos em uma faixa contínua para verificar a primalidade de números individuais muito grandes, o crivo perde o sentido. Aí entram os testes probabilísticos e determinísticos. O teste de Miller-Rabin é o padrão da indústria para a maioria das aplicações práticas, e ele entrega velocidade com margem de erro controlada. Para números abaixo de 3,319 × 10^6, as bases 2, 7 e 61 são suficientes para um resultado determinístico. Para intervalos maiores, a escolha das bases muda conforme o limite, e tabelas consolidadas indicam combinações seguras que evitam falsos positivos sem precisar recorrer a fatoração. O teste de AKS existe e é importante academicamente por ser determinístico e polinomial, mas ele não costuma ser a escolha prática. A velocidade dele fica abaixo de Miller-Rabin na maior parte dos cenários reais, e eu já vi equipes trocarem AKS por Miller-Rabin com bases fixas justamente para ganhar performance em pipelines que precisam validar milhares de candidatos por segundo. Se o seu requisito é certidão absoluta para um único número acima de 10^18, o que vale a pena é combinar Miller-Rabin com uma verificação posterior por Lucas ou usar bibliotecas estabelecidas que embutem essas camadas, como OpenSSL ou libsodium, ao invés de implementar manualmente.
Pitfalls que aparecem de verdade
Um dos erros mais frequentes é confiar em funções de biblioteca que supostamente retornam todos os primos sem expor o limite interno. Muitas delas param em 2^31 ou em valores que variam conforme a versão, e quem não verifica acaba gerando listas incompletas e acreditando que estão completas. Outro problema comum é a interpretação errada da função sieve[0] e sieve[1]: esses índices nunca são primos, mas implementações apressadas esquecem de marcá-los como compostos no início, o que gera respostas absurdas em validações. A seleção de bases em Miller-Rabin também é uma armadilha real. Usar apenas a base 2 parece eficiente, mas existem pseudoprimos que passam nesse teste e falham em outros contextos. Se você precisa de rigor criptográfico ou de garantia matemática, a prática segura éfixar um conjunto de bases conhecido para o intervalo-alvo e documentar essa escolha. Além disso, existe um viés de performance que muitas vezes passa despercebido: rodar um crivo simples para faixas menores de 10 milhões pode ser mais rápido que configurar um crivo segmentado, porque a sobrecarga de inicialização e gerenciamento de segmentos compensa apenas a partir de certos limites. Eu media esse ponto de virada em torno de 50 a 100 milhões de elementos, dependendo da arquitetura.
O que funciona no dia a dia
Para a maioria das pessoas que precisa de listas de primos, a solução mais estável é dividir o problema em três camadas. A primeira é um crivo de Eratóstenes otimizado para faixas até algumas centenas de milhões, com armazenamento bit-a-bit e eliminação de múltiplos ímpares. A segunda é um crivo segmentado para intervalos grandes que não cabem na memória de uma vez. A terceira é Miller-Rabin com bases fixas para verificação pontual de candidatos grandes. Combinar essas três abordagens evita que você dependa de uma única técnica e cobre os cenários comuns sem improvisação. Se o objetivo é apenas consultar todos os números primos sem programar, tabelas pré-computadas e arquivos compactados de primos conhecidos existem em repositórios públicos, mas é preciso validar a integridade com hashes e, se possível, cruzar com pelo menos uma fonte secundária. Arquivos gerados automaticamente por scripts caseiros frequentemente carregam erros de indexação ou truncamento silencioso, especialmente quando o processo foi interrompido por falta de memória ou tempo de execução. Uma verificação rápida com soma de verificação e contagem de registros costuma revelar inconsistências que passariam despercebidas em uma leitura superficial.
Limitações honestas
Nenhuma abordagem única resolve todos os casos. O crivo clássico falha por memória em intervalos muito largos. O crivo segmentado ganha espaço, mas introduz complexidade de implementação e depende de uma fase preliminar de geração de primos base, o que significa que você ainda precisa de um método confiável para os primeiros milhares de primos. Miller-Rabin é rápido, mas é probabilístico por natureza, a menos que você aplique conjuntos de bases validados, e mesmo assim ele não fatora — ele apenas testa primalidade. Se o requisito inclui fatoração ou geração de pares primos para criptografia, o caminho muda completamente e exige bibliotecas especializadas, não scripts próprios. O custo real de manter um gerador doméstico de primos é subestimado na maioria das vezes. Pequenos erros de offset, tratamento incorreto de bordas e escolhas ingênuas de estruturas de dados aparecem como falhas intermitentes que parecem aleatórias, mas na verdade são consistentes com o tipo de erro que se instala quando a validação não é rigorosa. Se você precisa de confiabilidade em produção, o recomendável é adotar bibliotecas maduras e fazer auditoria periódica dos resultados contra bases de referência conhecidas, em vez de depender exclusivamente de implementações internas.
