leto / math--primality Goto Github PK

It will be useful to have a benchmark test, (probably in xt/) so we can test the performance change of code against Math::Prime::Util :

http://search.cpan.org/~danaj/Math-Prime-Util-0.11/lib/Math/Prime/Util.pm

There are various optimizations for the AKS algorithm but if I recall correctly, the "naive" AKS algorihm is O(n^12). @bubaflub, can you add some info to the Math::Primality::AKS pod about the approximate running time of the current implementation?

From this paper:

http://www.cse.iitk.ac.in/users/manindra/algebra/primality_v6.pdf

Should we skip this and just implement the even-more optimized algorithms of DJB?

is_strong_pseudoprime(367, 1101) returns 0 (1101 = 367*3)

The function needs to either indicate using bases >= n are invalid, or do something like (pseudocode):

if (base >= n)
base %= n
if (base <= 1 || base == n-1)
return 1

The first protects us from mistakes such as indicating primes are composites when the base is a multiple of n. The latter opens up better deterministic tests since it won't return wrong answers.

I'll put a patch on my todo list unless someone gets to it first.

Do it.

I just released a version of Math::Prime::Util::GMP with ECPP (Elliptic Curve Primality Proving). With a small set of fixed determinants, it's good for proving 700-bit (216 digit) primes in ~1 second, including a certificate. Adding this to Math::Primality would be nice.

There are a number of improvements that could be made to my implementation to support larger sizes -- at 400 digits or so it occasionally gets bogged down in factoring due to a FPS strategy (basically go depth first and don't backtrack even if we get stuck trying to crack factors off huge numbers that won't cooperate). Adding simple backtracking would help, but once we get much over 500 digits that starts breaking down also (if we get stuck at the top level there's nowhere to backtrack to). I can add more fixed discriminants which delays the issue at the expense of memory.

The algorithm itself is relatively straightforward, but it needs a lot of support polynomial functions as well as some basic factoring (a good Pollard n-1 works wonders, and a good ECM is recommended also). Some of these have CPAN modules that may or may not work (e.g. polynomial root finding), and a lot of the rest should be in Math::Polynomial (i.e. it's already there or should be added if not).

In the long run, making your own Hilbert and Weber polynomials using Math::MPFR would be a big win, especially if you have fast root finding.

Currently we have Math::Primality::BigPolynomial, which basically allows you to create univariate polynomials with Math::GMPz objects as coefficients.

Last night I was going to extract BigPolynomial out to it's own CPAN module, but I ran across Math::Polynomial, which allows arbitrary objects as coefficients of univariate polynomials.

It seems like we could remove the need for M::P::BigPolynomial if we have Math::Primality::AKS use Math::Polynomial with Math::GMPz objects. This would also mean moving the mpz_* functions out of M::P::BigPolynomial back into M::P::AKS, which is probably where they belong, for now.

Any comments about this, @bubaflub ?

Implement the algorithm from http://www.ams.org/mcom/1996-65-213/S0025-5718-96-00674-6/S0025-5718-96-00674-6.pdf

There are various implementations given and described here:

http://www.mersenneforum.org/showthread.php?p=182647

Some of these implementations are faster than BPSW for numbers that fit in 32 or 64 bits.

Merging the fix_aks branch is blocked on some bugs that look related to getCoef not doing what we expect sometimes. We should test this function so we know what to expect. /cc @bubaflub