Resposta rápida: nunca, para fins práticos. Atualmente não é de uso prático.
Primeiro, vamos separar o teste de composição "prático" das provas de primalidade. O primeiro é bom o suficiente para quase todos os propósitos, embora existam diferentes níveis de teste que as pessoas consideram adequados. Para números abaixo de 2 ^ 64, não são necessários mais de 7 testes de Miller-Rabin ou um teste de BPSW para uma resposta determinística. Isso será muito mais rápido que o AKS e será igualmente correto em todos os casos. Para números acima de 2 ^ 64, o BPSW é uma boa opção, com alguns testes adicionais de base aleatória de Miller-Rabin, adicionando mais confiança por um custo muito baixo. Quase todos os métodos de prova começarão (ou deveriam) com um teste como esse, porque é barato e significa que só fazemos o trabalho duro com números quase certamente primos.
Passando para as provas. Em cada caso, a prova resultante não requer conjecturas; portanto, elas podem ser comparadas funcionalmente. A "pegadinha" do APR-CL é que não é bem polinomial, e a "pegadinha" do ECPP / fastECPP é que podem existir números que demoram mais que o esperado.
No gráfico, vemos duas implementações de software livre AKS - a primeira do artigo v6, a segunda incluindo melhorias de Bernstein e Voloch e uma boa heurística de r / s de Bornemann. Eles usam segmentação binária no GMP para as multiplicações polinomiais, por isso são bastante eficientes e o uso de memória não é um problema para os tamanhos considerados aqui. Eles produzem boas linhas retas com uma inclinação de ~ 6,4 no gráfico de log-log, o que é ótimo. Mas extrapolar para 1.000 dígitos chega em tempos estimados entre centenas e milhares e milhões de anos, contra alguns minutos para APR-CL e ECPP. Existem outras otimizações que poderiam ser feitas a partir do artigo de Bernstein de 2002, mas não acho que isso mude materialmente a situação (embora até a implementação isso não esteja comprovado).
Eventualmente, a AKS vence a divisão de testes. O método do teorema BLS75 5 (por exemplo, prova n-1) requer fatoração parcial de n-1. Isso funciona muito bem em tamanhos pequenos, e também quando temos sorte e o n-1 é fácil de fatorar, mas eventualmente ficaremos presos tendo que fatorar alguns semi-primos grandes. Existem implementações mais eficientes, mas realmente não ultrapassam os 100 dígitos, independentemente. Podemos ver que o AKS passará nesse método. Portanto, se você fez a pergunta em 1975 (e tinha o algoritmo AKS naquela época), poderíamos calcular o cruzamento de onde o AKS era o algoritmo mais prático. Mas no final dos anos 80, o APR-CL e outros métodos ciclotômicos eram a comparação correta e, em meados dos anos 90, teríamos que incluir o ECPP.
Os métodos APR-CL e ECPP são implementações de código aberto. O Primo (ECPP gratuito, mas não de código aberto) será mais rápido para tamanhos de dígitos maiores e tenho certeza que tem uma curva melhor (ainda não fiz novos testes comparativos). O APR-CL não é polinomial, mas o expoente possui um fator logloglogn que, como alguém brincou "vai ao infinito, mas nunca foi observado". Isso nos leva a crer que, em teoria, as linhas não se cruzariam para nenhum valor de n onde AKS terminaria antes que nosso sol se dissolvesse. O ECPP é um algoritmo de Las Vegas, pois quando obtemos uma resposta 100% correta, esperamos um resultado em O(log5+ϵ(n)) conjecturado ( log 5 + ϵ ( n ) ) (ECPP) ouO(log4+ϵ(n)) ("fastECPP"), mas pode haver números que demoram mais tempo. Portanto, nossa expectativa é que o AKS padrão seja sempre mais lento que o ECPP para quase todos os números (certamente se mostrou assim para números de até 25 mil dígitos).
O(log4+ϵ(n))(lgn)4+o(1)(lgn)4+o(1)
Alguns desses algoritmos podem ser facilmente paralelizados ou distribuídos. AKS com muita facilidade (cada teste é independente). O ECPP não é muito difícil. Não tenho certeza sobre o APR-CL.
Os métodos ECPP e BLS75 produzem certificados que podem ser verificados de forma independente e rápida. Essa é uma enorme vantagem sobre o AKS e o APR-CL, onde apenas precisamos confiar na implementação e no computador que o produziu.
openssl pkeyparam -text
para extrair a cadeia hexadecimal) usando os PARI'sisprime
(APR-CL como indicado): cerca de 80s em um notebook rápido. Para referência, o Chromium precisa de um pouco mais de 0,25s para cada iteração da minha implementação de demonstração JavaScript do teste Frobenius (que é muito mais forte que o MR), portanto o APR-CL é certamente paranóico, mas factível.vi esse artigo recente sobre o arxiv, que analisa esse tópico em profundidade / detalhe, sem saber o que as pessoas pensam dele, não ouviu reações até agora, parece uma tese criada por um aluno, mas possivelmente uma das análises mais detalhadas / abrangentes de uso prático do algoritmo disponível.
Teste determinístico de primazia - compreendendo o algoritmo AKS Vijay Menon
Algoritmos poderosos e complexos demais para implementar tcs.se
fonte