PRPNet 3.0.0 Released

[rogue]

I fixed the GMT issue from 3.3.4. It will now display the correct time zone in the logs. Thanks to Max for testing.

You can d/l it from here.

[henryzz]

I am using a 3.2.5 client on a 3.3.4(probably soon to be 3.3.5) server. Is that likely to cause any problems? It seems to be working fine. I just don't want to inconvinience NPLB.

[mdettweiler]

Originally Posted by henryzz

I am using a 3.2.5 client on a 3.3.4(probably soon to be 3.3.5) server. Is that likely to cause any problems? It seems to be working fine. I just don't want to inconvinience NPLB.

I'm doing the same thing myself--my quad is still running 3.2.5 and (as of today) all the NPLB, CRUS and personal servers are on 3.3.5 (though they identify themselves as 3.3.4). There were no communication protocol changes between 3.2 and 3.3, so there's no problem there.

I believe the only major changes between 3.2.5 and 3.3.5 for the client were 1) changing the behavior of startoption=1 so it exits after canceling its queue (like LLRnet with the -c flag) and 2) the console and log outputs now report time in local time instead of GMT. There were also a few smallish bug fixes in there but those may have been for issues introduced since 3.2.5.

[rogue]

Originally Posted by henryzz

I am using a 3.2.5 client on a 3.3.4(probably soon to be 3.3.5) server. Is that likely to cause any problems? It seems to be working fine. I just don't want to inconvinience NPLB.

I state in the release notes if there are any compatibility issues between releases. For example, if I come out with release a.b.c, I will state if it is incompatible with older releases. Sometimes the server is affected, sometimes the client, sometimes both. Sometimes I retain support for older releases, but deprecate it so that users have a chance to get clients updated. This is not always possible.

[rogue]

If anyone is using PRPNet for a twin prime search, please let me know. With the changes I am working on for 3.4.0, the database conversion will be tricky for that type of search.

[rogue]

The only change from 3.3.5 to 3.3.6 is in the server. It gives the ability to log in either GMT or local time zone via a switch in the prpserver.ini file called localtime=. The default is local time zone. To use GMT, set it to localtime=0.

You can d/l it from here.

[rogue]

I have compiled a list of the modifications for PRPNet 3.4.0. The coding is mostly completed and I have just started my testing. If there are additional features that anyone would like in 3.4.0, please let me know.

• all: Added support for Sophie/Germain prime searches.
• all: Fixed many compiler warnings on *nix.
• client: Much of this has been rewritten to support Sophie/Germain and other prime searches, such as Cunningham chains (which has yet to be written). One result of this is that the client will log more messages for certain server types.
• client: Added support for usellroverpfgw setting from server. When set, the client will use LLR instead of PFGW for primality tests.
• client: Always check for GFN divisiblity when b = 2 and c = 1. This could happen for Twin and Sophie-Germain prime searches.
• client: Stripped "<candidate> is a Factor of" from GFN divisors.
• server: As part of the Sophie-Germain prime search, the server will now log additional messages for that server type.
• server: Reworked e-mail messages to be a little more readable.
• server: Added user_gfns.html webpage for GFN divisors by user.
• server: Added projectname= to prpserver.ini for the Prime Pages project name.
• server: Added usellroverpfgw= option to prpserver.ini.
• server: Modified sortoption= in prpserver.ini to provide maximum flexibility.
• server: Show if candidate was prime or PRP on user_primes.html.
• server: Significantly improved speed loading of Candidates via prpadmin.

The new server will be backward compatible clients from PRPNet 3.2.x and 3.3.x. The new client will be backward compatible with servers from PRPNet 3.2.x and 3.3.x.

Some of the MySQL tables on the server have changed quite a bit. I have a script to do the updates.

Setting usellroverpfgw does not preclude clients from running phrot or PFGW. LLR will try to use base 3 to do the primality test, but if it cannot use that base, then it will use a base that will result in a residue that will not match the residue from phrot/pfgw. If the server is set up to do double-checks, then it is likely that the server will send out some triple checks if there are clients using only phrot or PFGW. At this time I am not open to excluding non-LLR clients from those servers for the main reason that few projects are doing double-checks and because I don't know how frequently a triple check will be required.

[mdettweiler]

Originally Posted by rogue

Setting usellroverpfgw does not preclude clients from running phrot or PFGW. LLR will try to use base 3 to do the primality test, but if it cannot use that base, then it will use a base that will result in a residue that will not match the residue from phrot/pfgw. If the server is set up to do double-checks, then it is likely that the server will send out some triple checks if there are clients using only phrot or PFGW. At this time I am not open to excluding non-LLR clients from those servers for the main reason that few projects are doing double-checks and because I don't know how frequently a triple check will be required.

In my experience, I've never seen LLR 3.8.x do a non-base-3 test on a number that turned out to be composite; only on PRPs (which are almost always prime). I always considered it the analogue to how PFGW sometimes needs to use additional bases in its N-1/N+1 tests for certain "tougher" proofs.

That said, I can see how it would be a problem in cases where it finds a number that comes out as "x may be prime" in base 3 then actually turns out to be composite in another base; in that case, the residue would be in the other base. However, that implies a composite PRP, which is exceedingly rare for numbers of the size that would be run through PRPnet.

Just curious, what particular scenarios have been reported to you in which this has been a problem before?

Edit: there is one scenario I can think of where it would be useful, namely when you have oddball bases like S208 that LLR can convert to base 2 but PRPnet doesn't recognize since they're not your ordinary power-of-2 case. See here for more information on this particular one. usellroverpfgw= would have solved this problem by allowing me to force use of LLR and therefore a base 2 Proth test for the whole range (though in this instance it's a moot point since I wasn't aware of base 208's being convertible to base 2 until after I was already nearly done with the range).

[rogue]

Originally Posted by mdettweiler

In my experience, I've never seen LLR 3.8.x do a non-base-3 test on a number that turned out to be composite; only on PRPs (which are almost always prime). I always considered it the analogue to how PFGW sometimes needs to use additional bases in its N-1/N+1 tests for certain "tougher" proofs.

That said, I can see how it would be a problem in cases where it finds a number that comes out as "x may be prime" in base 3 then actually turns out to be composite in another base; in that case, the residue would be in the other base. However, that implies a composite PRP, which is exceedingly rare for numbers of the size that would be run through PRPnet.

Just curious, what particular scenarios have been reported to you in which this has been a problem before?

Edit: there is one scenario I can think of where it would be useful, namely when you have oddball bases like S208 that LLR can convert to base 2 but PRPnet doesn't recognize since they're not your ordinary power-of-2 case. See here for more information on this particular one. usellroverpfgw= would have solved this problem by allowing me to force use of LLR and therefore a base 2 Proth test for the whole range (though in this instance it's a moot point since I wasn't aware of base 208's being convertible to base 2 until after I was already nearly done with the range).

This is isn't a problem with base 2. It is a problem with other bases. Previously LLR would always do a PRP test with base 3, but LLR 3.8 will choose the lowest base that can yield a primality proof. Frequently that will not be base 3. The chosen base has to do with the base of the number being tested, the value of k and the value of n. For example using base 3 for a PRP test is not helpful for numbers in the form k*3^n+/-1.

[mdettweiler]

Originally Posted by rogue

This is isn't a problem with base 2. It is a problem with other bases. Previously LLR would always do a PRP test with base 3, but LLR 3.8 will choose the lowest base that can yield a primality proof. Frequently that will not be base 3. The chosen base has to do with the base of the number being tested, the value of k and the value of n. For example using base 3 for a PRP test is not helpful for numbers in the form k*3^n+/-1.

Hmm, I didn't know that. I always found LLR 3.8's residues to be compatible with PFGW's in my limited testing, but I suppose I could have just happened to hit ones that worked with base 3.

How does PFGW handle k*3^n+-1 tests when you don't specify the -b option on the command line? I know that 3^n+-1 numbers will always come back 3-PRP, but I thought k*3^n+-1 was exempt from that. I was under the assumption that we've been using base 3 PRP tests with PFGW on our R3/S3 efforts all along. Before that, we used LLR 3.7.1 for all our PRP tests, and AFAIK that's hardcoded to do base 3. I'm pretty sure that PFGW always reported the primes as "3-PRP".

Edit: ah, here we go. This is a log snippet Karsten posted a while back while doing a file from one of our S3 mini-drives:

PFGW Version 20090723.Win_Dev (Beta 'caveat utilitor') [GWNUM 25.12]
 
Output logging to file pfgw.out
Recognized ABC Sieve file: 
ABC File Processing for at most 1 Primes
 
196996994*3^25147+1 is 3-PRP! (2.6909s+0.0006s)
PRP: 196853336*3^25152+1 10000/39892

I'm assuming that "is 3-PRP!" means that it definitely was done with a 3-PRP test, right?

[mdettweiler]

To get some hard data for this, I did a quick sieve to generate 20 Riesel base 3 candidates (all of which are composite), added a known prime of similar n-value to the end of the file, and ran it with the latest versions of both PFGW and LLR. Here's what I got with PFGW:

2*3^25022-1 is composite: RES64: [DED212655BA98987] (2.6341s+0.1114s)
2*3^25023-1 is composite: RES64: [4EB022B2F63243C3] (2.4142s+0.0075s)
2*3^25032-1 is composite: RES64: [37594E82809FE8BB] (2.4301s+0.0020s)
2*3^25063-1 is composite: RES64: [8E4BED8122D61CE0] (2.2592s+0.0011s)
2*3^25082-1 is composite: RES64: [EDA98F28D3780451] (2.2772s+0.0213s)
2*3^25087-1 is composite: RES64: [C880EC3200CB7AAA] (2.2662s+0.0254s)
2*3^25107-1 is composite: RES64: [6967C6B717EFDD97] (2.1421s+0.0152s)
2*3^25110-1 is composite: RES64: [D657DB8813FC4D38] (2.3583s+0.0012s)
2*3^25135-1 is composite: RES64: [9EC49584A72F2213] (2.3390s+0.0108s)
2*3^25147-1 is composite: RES64: [7BB507739F905F12] (2.2193s+0.0106s)
2*3^25148-1 is composite: RES64: [D4DD8F536EAF0932] (2.3149s+0.0011s)
2*3^25158-1 is composite: RES64: [775B289BAA3BA174] (3.4298s+0.0012s)
2*3^25159-1 is composite: RES64: [5A3045986ABD6CD8] (2.5303s+0.0313s)
2*3^25160-1 is composite: RES64: [67F808F5C0527B3B] (2.5386s+0.0524s)
2*3^25163-1 is composite: RES64: [0F18BF8C6E578B13] (2.3178s+0.0007s)
2*3^25220-1 is composite: RES64: [65D4C40FA3F7ECBE] (2.3814s+0.0035s)
2*3^25232-1 is composite: RES64: [AB988452DB448476] (2.0174s+0.0200s)
2*3^25243-1 is composite: RES64: [0254FA500386130B] (2.2445s+0.0033s)
2*3^25255-1 is composite: RES64: [71EC38B4E33BA5EB] (2.2930s+0.0040s)
2*3^25262-1 is composite: RES64: [5731DA651D44C909] (2.5433s+0.0036s)
50633872*3^25032-1 is 3-PRP! (5.5628s+0.0313s)

And with LLR:

2*3^25022-1 is not prime.  RES64: DED212655BA98987.  OLD64: E4CB1AEFC3875A21  Time : 2.190 sec.
2*3^25023-1 is not prime.  RES64: 4EB022B2F63243C3.  OLD64: EC106818E296CB46  Time : 2.033 sec.
2*3^25032-1 is not prime.  RES64: 37594E82809FE8BB.  OLD64: AF5D0FD7E5A927AC  Time : 2.148 sec.
2*3^25063-1 is not prime.  RES64: 8E4BED8122D61CE0.  OLD64: DCB87D8BF819B488  Time : 2.176 sec.
2*3^25082-1 is not prime.  RES64: EDA98F28D3780451.  OLD64: 1E2A825554AFF74E  Time : 2.194 sec.
2*3^25087-1 is not prime.  RES64: C880EC3200CB7AAA.  OLD64: C6C34A749B842AA6  Time : 2.176 sec.
2*3^25107-1 is not prime.  RES64: 6967C6B717EFDD97.  OLD64: 3C37542547CF98C2  Time : 2.109 sec.
2*3^25110-1 is not prime.  RES64: D657DB8813FC4D38.  OLD64: 959E79F048E46743  Time : 2.187 sec.
2*3^25135-1 is not prime.  RES64: 9EC49584A72F2213.  OLD64: 880824587C785261  Time : 2.062 sec.
2*3^25147-1 is not prime.  RES64: 7BB507739F905F12.  OLD64: E4719B960A11DEBE  Time : 2.147 sec.
2*3^25148-1 is not prime.  RES64: D4DD8F536EAF0932.  OLD64: 2687CD5D5051A4D1  Time : 2.092 sec.
2*3^25158-1 is not prime.  RES64: 775B289BAA3BA174.  OLD64: 661179D2FEB2E459  Time : 2.349 sec.
2*3^25159-1 is not prime.  RES64: 5A3045986ABD6CD8.  OLD64: 0E90D0C940384685  Time : 2.216 sec.
2*3^25160-1 is not prime.  RES64: 67F808F5C0527B3B.  OLD64: 836C3AAFC9D5F72C  Time : 2.074 sec.
2*3^25163-1 is not prime.  RES64: 0F18BF8C6E578B13.  OLD64: A8C1EC0982C2AB41  Time : 2.065 sec.
2*3^25220-1 is not prime.  RES64: 65D4C40FA3F7ECBE.  OLD64: 317E4C2EEBE7C637  Time : 3.152 sec.
2*3^25232-1 is not prime.  RES64: AB988452DB448476.  OLD64: 8CAE6E8036E0A85D  Time : 2.198 sec.
2*3^25243-1 is not prime.  RES64: 0254FA500386130B.  OLD64: 87141038C05B0DA9  Time : 2.208 sec.
2*3^25255-1 is not prime.  RES64: 71EC38B4E33BA5EB.  OLD64: 2E7159049E7D95A9  Time : 3.134 sec.
2*3^25262-1 is not prime.  RES64: 5731DA651D44C909.  OLD64: 10CFB5B196F4AB27  Time : 2.771 sec.
50633872*3^25032-1 is prime! (P = 12)  Time : 35.007 sec.

I checked the residues and they all matched. For each of the composites, LLR used exclusively base 3 for its tests:

Base prime factor(s) taken : 3
Starting N+1 prime test of 2*3^25262-1
Using FFT length 2048, a = 3
 
2*3^25262-1 is not prime.  RES64: 5731DA651D44C909.  OLD64: 10CFB5B196F4AB27  Time : 2.771 sec.

Only for the prime did it have to do something different:

Base prime factor(s) taken : 3
Starting N+1 prime test of 50633872*3^25032-1
Using zero-padded FFT length 4K, a = 3
50633872*3^25032-1 may be prime. Starting Lucas sequence...
Using zero-padded FFT length 4K, P = 5
50633872*3^25032-1 may be prime, trying to compute gcd's
50633872*3^25032-1 may be prime, but N divides U((N+1)/3), P = 5
Restarting Lucas sequence with P = 11
Using zero-padded FFT length 4K, P = 11
50633872*3^25032-1 may be prime, trying to compute gcd's
50633872*3^25032-1 may be prime, but N divides U((N+1)/3), P = 11
Restarting Lucas sequence with P = 12
Using zero-padded FFT length 4K, P = 12
50633872*3^25032-1 may be prime, trying to compute gcd's
U((N+1)/3) is coprime to N!
50633872*3^25032-1 is prime! (P = 12)  Time : 35.007 sec.

So it seems that LLR uses base 3 almost all the time, and only uses other bases to retry for a proof when base 3 returns "may be prime". (Note that I'm not entirely sure it means it's doing a base 3 test when it says "a = 3" or the like, since I could have sworn that earlier tests I did showed other values there and still produced PFGW-base-3-compatible residuals.)