Sierp base 3 reservations/statuses/primes

[rogue]

Originally Posted by gd_barnes

The GWNUM libraries still seem to have a bug. I'm not going to test them here but I'll make a prediction: All of the compPRP's with an exponent < 50 are actually composite but the compPRP's with an exponent >= 50 are actually prime. So the n<50 compPRPs are correct as shown. Of course this doesn't make a difference for the proof of the conjecture since it appears that you found higher primes for all of the k's.

I have found tons of compPRP's on Sierp base 63 with an exponent >= 100 that turned out to actually be prime. As a matter of fact, just like for base 3 with an exponent >=50, ALL compPRP's on Sierp base 63 with an exponent >= 100 turned out to be prime. There were no composites. In several cases, the k shows as remaining at n=1000 and I had to go back and test the compPRP with other software just to make sure that the k could be removed.

I have one comment, which I know has been stated before because I stated it. If anyone believes that they have uncovered a bug, I would prefer that they contact me first rather than stating it publicly in a forum. This is a very aggressive tactic that not only frustrates me (and others) but puts people on the defensive.


I would state that it is premature to blame gwnum for the problems you are seeing. Please PM (or e-mail) me the relevant information regarding the problem. I need to know which version of PFGW you are using and the test cases that can reproduce the problem.

[gd_barnes]

Originally Posted by rogue

I have one comment, which I know has been stated before because I stated it. If anyone believes that they have uncovered a bug, I would prefer that they contact me first rather than stating it publicly in a forum. This is a very aggressive tactic that not only frustrates me (and others) but puts people on the defensive.


I would state that it is premature to blame gwnum for the problems you are seeing. Please PM (or e-mail) me the relevant information regarding the problem. I need to know which version of PFGW you are using and the test cases that can reproduce the problem.

I'm sorry Mark. I thought that a related GWNUM bug had been brought out publicly before that caused relatively small primes (but not VERY small primes) to show up as composite (upon an attempted proof) and that it was not a bug in PFGW. I'm also fairly certain that LLR 3.8 was showing the same problem, which made me further think that it must be GWNUM.

I know I've been publicly critical before but in no way intended that this be a criticism of GWNUM. I was merely stating the symptoms of what I thought was a known problem. I'm sorry if the tone sounded otherwise.

Would you like a list of the PRPs where a proof showed "actual primes" to be composite on bases 3 and 63? It seems to only happen on fairly specific sizes of PRPs. That is around n=50-75 or n=100-120 on base 3 and I've only seen it for n=100-120 on base 63.

I am running PFGW 3.3.2. The above is definitely not a bug introduced in any subsequent releases of PFGW since the new speedy GWNUM libraries were introduced that sped it up nearly 5 times. I'm getting the same problem in older releases of PFGW back to 3.2.3.

It will take me a little while to put the list together but can do it if you think it will help. You can also generate a few yourself by running a k=1M range of Sierp base 63 using the starting bases script with trial factoring set to 10% (-f10). [I haven't checked to see if the trial factoring % would make any difference.] Any CompPRP with an exponent of n>100 is actually prime. I've verified this for all k<=20M now. I estimate that there are about 100 of them. As you know, I'm continuing that doublecheck up to the conjectore of k=~37M.

Interestingly, there are a gob of compPRPs on both bases 3 and 63 with an exponent of n<20. All of those are actually composite. So...it's a very specific size of PRP that causes the problem. If you think a list of the "truly composite" CompPRPs would help, I can also forward those.


Gary

[rogue]

Since PFGW 3.3.3 is using a newer version of gwnum, I think it is important to see if that version is exhibiting the same problems that you see in PFGW 3.3.2. If it does, then please post any numbers causing problems.

[gd_barnes]

Originally Posted by rogue

Since PFGW 3.3.3 is using a newer version of gwnum, I think it is important to see if that version is exhibiting the same problems that you see in PFGW 3.3.2. If it does, then please post any numbers causing problems.

The same problem has existed ever since PFGW 3.2.3. I've tested every version so...I guess I'll test another. Can you please provide a direct link to the Windows and Linux versions of PFGW 3.3.3? I'll then test all of them and post the problem ones.

Thanks.

[Lennart]

Originally Posted by gd_barnes

The same problem has existed ever since PFGW 3.2.3. I've tested every version so...I guess I'll test another. Can you please provide a direct link to the Windows and Linux versions of PFGW 3.3.3? I'll then test all of them and post the problem ones.

Thanks.

http://sourceforge.net/projects/openpfgw/files/

Try this It use to be here.

Lennart

[gd_barnes]

Originally Posted by Lennart

http://sourceforge.net/projects/openpfgw/files/

Try this It use to be here.

Lennart

OK, thanks Lennart. I guess we're already at version 3.3.4 so I'll test with that against the many compPRP's that are coming out of bases R3, S3, and S63.

BTW, I have a question for you since you have a lot of cores. How do you easily keep the latest versions of everything on all of them? I find it very time-consuming to update to new versions of things fairly often. I suppose if you only use a PRPnet server on most of them, that helps, although it still needs to have the latest PFGW, LLR, etc. in it.

I've been using PFGW 3.3.2 on my 2 Windows machines, which is what I used to test the above bases but PFGW 3.3.0 on the rest of my machines that are Linux. I'll finally take the time to update everything to 3.3.4 later today but it just takes a while. I have ~50 cores.

[Lennart]

BTW, I have a question for you since you have a lot of cores. How do you easily keep the latest versions of everything on all of them? I find it very time-consuming to update to new versions of things fairly often. I suppose if you only use a PRPnet server on most of them, that helps, although it still needs to have the latest PFGW, LLR, etc. in it.

I've been using PFGW 3.3.2 on my 2 Windows machines, which is what I used to test the above bases but PFGW 3.3.0 on the rest of my machines that are Linux. I'll finally take the time to update everything to 3.3.4 later today but it just takes a while. I have ~50 cores.

I use our prpclient package on all my computers, that means I have one main folder "program" In that folder I have all programfiles like PRPclient,cllr,pfgw,phrot,genefer,etc. I'll stop all work and abandoned all.

I copy the update file to "program" run install. and all core folders are updated. Then I start again

If there is more changes I do a main package and download them to each
computer Edit computer ID run install & update, ready to run.

Lennart

[gd_barnes]

Originally Posted by rogue

You need to upgrade to 3.3.3 (in the minimum). PFGW was upgraded to use gwnum 25.14 in that release. The problems you are describing are most likely fixed in 3.3.4 based upon this change in gwnum:

More conservative in selecting an FFT length for non-base-2 cases.

Well, I'm happy to see that a longstanding problem appears to have been completely fixed. After upgrading to version PFGW 3.3.4, all compPRP's in Ian's list with n>=50 are correctly showing up as prime. To be specific, the following are now correctly showing as prime in PFGW 3.3.4 with the -t switch set on:
333388184*3^67+1
335550520*3^55+1
336267398*3^79+1
338985326*3^71+1

I doublechecked all of the compPRPs using Alpertron's applet at http://www.alpertron.com.ar/ECM.HTM. All of the above are actually prime and the rest of them are actually composite.

At least I was right on one thing. All n>=50 were prime and all n<50 were composite.

Ian, I think 3.3.4 is a keeper. I'd definitely suggest using it for base 3 in the future due to the huge quantity of small primes and composite PRPs that we run into. Lennart's posted link was easy to download both the Windows and Linux versions of it.

I will start running my compPRP files from S63 thru 3.3.4 on Tuesday. Since my issues were consistent with the above, I anticipate no problems now.

Nice work by the GWNUM guys!


Gary

[rogue]

Originally Posted by gd_barnes

Well, I'm happy to see that a longstanding problem appears to have been completely fixed. After upgrading to version PFGW 3.3.4, all compPRP's in Ian's list with n>=50 are correctly showing up as prime. To be specific, the following are now correctly showing as prime in PFGW 3.3.4 with the -t switch set on:
333388184*3^67+1
335550520*3^55+1
336267398*3^79+1
338985326*3^71+1

Nice work by the GWNUM guys!

That is great news. If George is reading this, then he will be very happy to read this.

Thanks to you and everyone else for being patient as we addressed these problems.

--Mark

[gd_barnes]

Originally Posted by rogue

That is great news. If George is reading this, then he will be very happy to read this.

Thanks to you and everyone else for being patient as we addressed these problems.

--Mark

Even better news:

I just ran PFGW 3.3.4 against 195 composite PRPs that I had previously found for k<22M for Sierp base 63 using PFGW 3.3.2. As verified by other software, it correctly reported back 132 primes and 63 composites. All composites were n<5. All primes were n>=14; some as high as n=~190.

New testing in the k=22M-30M range is coming back with only composite PRPs for n<5. Testing with other software confirmed that they are all composite; consistent with all composites for n<5 for k<22M.

I'm now confident in not having to check compPRP's anymore, although I still do because their factorization is kind of interesting.

It looks like we're nearing a much more stable phase on both PFGW and PRPnet.

Nice work by both you and George to nail down what must have been an extremely complex issue in the GWNUM libraries.

I assume that a new version of LLR will also come out, if it hasn't already, that uses use the new GWNUM libraries.


Gary

[mdettweiler]

Originally Posted by gd_barnes

I assume that a new version of LLR will also come out, if it hasn't already, that uses use the new GWNUM libraries.

See here--Jean released 3.8.1 as a beta version yesterday.