Build 5 now ready.

Adds newline to "sending interim residue" log file message. Does not Jacobi test if GMP version is not at least 5.0.0.

[QUOTE=Prime95;471585]Build 5 now ready.

[...] Does not Jacobi test if GMP version is not at least 5.0.0.[/QUOTE]

Actually, this should be 5.1.0

My bad, I gave the wrong version initially. I misread the [URL="https://gmplib.org/list-archives/gmp-devel/2010-January/001451.html"]old mailing list message[/URL] that I linked to [URL="http://mersenneforum.org/showthread.php?p=471534#post471534"]in the other thread[/URL].

It actually said:

[QUOTE]
GMP 5.0.0 implements a quadratic algorithm for the Jacobi symbol. In
[url]http://wwwmaths.anu.edu.au/~brent/pub/pub236.html[/url] we describe a subquadratic
algorithm
[/QUOTE]

In other words, GMP 5.0.0 still had the older slow (quadratic) code.

Doing a little digging, it was actually GMP 5.1.0 that introduced the faster (subquadratic) code, see [url]https://gmplib.org/gmp5.1.html[/url] or [url]https://gmplib.org/list-archives/gmp-announce/2012-December/000036.html[/url]

Looking at the old versions of various distros:

Ubuntu 14.04 LTS (trusty) uses GMP 5.1
Ubuntu 16.04 LTS (xenial) uses GMP 6.0
Latest version of Ubuntu is 17.10 (artful)

Debian 7.0 (wheezy) uses GMP 5.0
Debian 8.0 (jessie) uses GMP 6.0
Latest version of Debian is 9.0 (stretch)

CentOS 6 and RedHat EL 6 use GMP 4.3
CentOS 7 and RedHat EL 7 use GMP 6.0

My first two PRP double checks completed successfully ([M]M75560141[/M] and [M]M75560141[/M]), matching preda's gpuOwL results.

When to run PRP vs LL?
 

Hi, are there any recommended guidelines to follow for deciding to run PRP vs LL on a given machine? Thanks!

[QUOTE=GP2;471596]My first two PRP double checks completed successfully ([M]M75560141[/M] and [M]M75560141[/M]), matching preda's gpuOwL results.[/QUOTE]Isn't it a waste of time to do PRP tests on an exponent where an LL test was done ? The same would apply to doing LL tests on exponents that already have a PRP result.

Shouldn't the two methods for proving the Mersenne number is composite be used exclusively on the the different candidates ?

Jacob

[QUOTE=S485122;471605]Isn't it a waste of time to do PRP tests on an exponent where an LL test was done ? The same would apply to doing LL tests on exponents that already have a PRP result.

Shouldn't the two methods for proving the Mersenne number is composite be used exclusively on the the different candidates ?

Jacob[/QUOTE]

I would argue that like DC-LL it has it's purpose. That purpose however, is not confirming the residue given by LL.

[QUOTE=S485122;471605]Isn't it a waste of time to do PRP tests on an exponent where an LL test was done ? [/QUOTE]

Yes, yes it is. I don't think this was officially sanctioned by TPTB.

[QUOTE=S485122;471605]Isn't it a waste of time to do PRP tests on an exponent where an LL test was done ? The same would apply to doing LL tests on exponents that already have a PRP result.

Shouldn't the two methods for proving the Mersenne number is composite be used exclusively on the the different candidates ?[/QUOTE]

Yes.

However, in this case the two separate first-time tests (LL and PRP) were already done. Hopefully, in the future there will be coordination to avoid this.

In my case, I simply set a few of my working directories to do PRP double checks (WorkPreference=151) and they do whatever exponents they are assigned.

[QUOTE=Runtime Error;471597]Hi, are there any recommended guidelines to follow for deciding to run PRP vs LL on a given machine? Thanks![/QUOTE]

PRP has better error correction, and should give very reliable results even on unreliable machines. It may eventually take over as the main form of testing. However, the Gerbicz error correction algorithm is very new, so adoption may be gradual and cautious. Meanwhile there are ten years' worth of old LL results that need double-checking.

PRP tests can prove a Mersenne number is composite, but can't mathematically prove that is prime (although there is a very high degree of confidence). LL tests do prove primality. This is a non-issue in practice, since Mersenne primes are extremely rare and credit will be given for any finds made with PRP testing even though a confirming LL test will be run subsequently.

The savefiles for PRP testing appear to be about three times larger than LL save files for equivalent exponents. Around 30MB vs. 10MB for exponents around the 80M range. Shouldn't be an issue unless you are extremely constrained for disk space or I/O throughput bandwidth (the latter may actually be an issue with the EFS filesystem on the AWS cloud if there is a low DiskWriteTime interval, low filesystem storage usage, and very frequent churning of spot instances).

The kinds of tests assigned by the default "whatever makes sense" setting will undoubtedly change over time. If that's what you use now, there's no need to change it.

I cannot find way to revert output of PRP to "old way" (like this - 4*332^458778+1 is not prime. RES64: DFFD7CC51D5214C7. Wf4: 4B7B7071,00000000)
Any command in prime.txt?

Is this a standard output right now? :cool:[code]{"status":"C", "k":127, "b":2, "n":12000569, "c":-1, "worktype":"PRP-3", "res64":"700854A79E1515ED", "residue-type":1, "fft-length":786432, "error-code":"00000000", "security-code":"6DAF586E", "program":{"name":"Prime95", "version":"29.4", "build":4, "port":4}, "timestamp":"2017-11-12 11:32:16", "errors":{"gerbicz":0}}[/code]
I haven't touched config files in a while, I guess from v28.9, and so far everything was OK.