El algoritmo de prueba de primalidad determinista (asintóticamente) más eficiente se debe a Lenstra y Pomerance , que se ejecuta en el tiempo . Si crees en la hipótesis extendida de Riemann, entonces el algoritmo de Miller se ejecuta en el tiempo . Hay muchos otros algoritmos deterministas de prueba de primalidad, por ejemplo, el artículo de Miller tiene un algoritmo , y otro algoritmo bien conocido es Adleman – Pomerance – Rumley, que se ejecuta en el tiempo .O~(log6n)O~(log4n)O~(n1/7)O(lognO(logloglogn))
En realidad, nadie usa estos algoritmos, ya que son demasiado lentos. En cambio, se utilizan algoritmos probabilísticos de prueba de primalidad, principalmente Miller – Rabin, que es una modificación del algoritmo de Miller mencionado anteriormente (otro algoritmo importante es Solovay – Strassen). Cada iteración de Miller – Rabin se ejecuta en tiempo , por lo que para una probabilidad de error constante (digamos ), todo el algoritmo se ejecuta en tiempo , que es mucho más rápido que Lenstra – Pomerance.O~(log2n)2−80O~(log2n)
En todas estas pruebas, la memoria no es un problema.
En su comentario, jbapple plantea la cuestión de decidir qué prueba de primalidad usar en la práctica. Esta es una cuestión de implementación y evaluación comparativa: implemente y optimice algunos algoritmos, y determine experimentalmente cuál es el más rápido en qué rango. Para los curiosos, los codificadores de PARI hicieron exactamente eso, y se les ocurrió una función determinista isprime
y una función probabilística ispseudoprime
, las cuales se pueden encontrar aquí . La prueba probabilística utilizada es Miller – Rabin. El determinista es BPSW.
Aquí hay más información de Dana Jacobsen :
Pari desde la versión 2.3 utiliza una prueba de primalidad APR-CL para isprime(x)
, y una prueba principal probable BPSW (con la prueba de Lucas "casi extra fuerte") ispseudoprime(x)
.
Ellos toman argumentos que cambian el comportamiento:
isprime(x,0)
(predeterminado). Utiliza una combinación (BPSW, Pocklington rápido o BLS75 teorema 5, APR-CL).
isprime(x,1)
Utiliza la prueba de Pocklington-Lehmer (simple ).n−1
isprime(x,2)
Utiliza APR-CL.
ispseudoprime(x,0)
(predeterminado). Usa BPSW (MR con base 2, Lucas "casi extra fuerte").
ispseudoprime(x,k)
(para ) Hace MR pruebas con bases aleatorias. El RNG se siembra de manera idéntica en cada ejecución de Pari (por lo que la secuencia es determinista) pero no se reinicia entre llamadas como lo hace GMP (las bases aleatorias de GMP son de hecho las mismas bases en cada llamada, por lo que si está mal una vez, siempre estará mal).k≥1kmpz_is_probab_prime_p(x,k)
Pari 2.1.7 utilizó una configuración mucho peor. isprime(x)
fueron solo pruebas de MR (por defecto 10), lo que condujo a cosas divertidas como isprime(9)
volver cierto con bastante frecuencia. El uso isprime(x,1)
haría una prueba de Pocklington, que estuvo bien durante aproximadamente 80 dígitos y luego se volvió demasiado lenta para ser generalmente útil.
También escribes En realidad, nadie usa estos algoritmos, ya que son demasiado lentos. Creo que sé a qué te refieres, pero creo que esto es demasiado fuerte dependiendo de tu audiencia. AKS, por supuesto, es increíblemente lento, pero APR-CL y ECPP son lo suficientemente rápidos como para que algunas personas los usen. Son útiles para la criptografía paranoica, y útiles para personas que hacen cosas como primegaps
o factordb
donde uno tiene tiempo suficiente para querer primos probados.
[Mi comentario al respecto: cuando buscamos un número primo en un rango específico, utilizamos un enfoque de tamizado seguido de algunas pruebas probabilísticas relativamente rápidas. Solo entonces, si es que lo hacemos, ejecutamos una prueba determinista.]
En todas estas pruebas, la memoria no es un problema. Es un problema para AKS. Ver, por ejemplo, este eprint . Algo de esto depende de la implementación. Si uno implementa lo que el video de numberphile llama AKS (que en realidad es una generalización del pequeño teorema de Fermat), el uso de la memoria será extremadamente alto. El uso de una implementación NTL del algoritmo v1 o v6 como el documento al que se hace referencia dará como resultado una gran cantidad de memoria estúpida. Una buena implementación de v6 GMP todavía usará ~ 2 GB para un prime de 1024 bits, que es muchode memoria para un número tan pequeño. El uso de algunas de las mejoras de Bernstein y la segmentación binaria GMP conduce a un crecimiento mucho mejor (por ejemplo, ~ 120 MB para 1024 bits). Esto sigue siendo mucho más grande de lo que necesitan otros métodos, y no es de extrañar, será millones de veces más lento que APR-CL o ECPP.