PFGW latest well-tested version

[rogue]

Originally Posted by Mini-Geek

Hm...in the mean time, is there something that could be added to the script to make it run the primality proof as -a1 (preferably only after returning "composite" on a PRP) so it can be more sure before assuming it's really a composite and putting it in pl_compPRP.txt?

PFGW scripts cannot specify the -a switch. I'll think about a change, but can't make any promises.

[KEP]

I'm seriously concerned about the value of our proofs. I just did a doublecheck of all the primes found using WinPFGW version 3.2.0, with WinPFGW version 3.3.0. Of the 311882 primes from n=1 to n=2500, 589 of them were confirmed primes by version 3.2.0, but failed to be primes using version 3.3.0! Please notice, that all 589 primes, tested out as PRPs in both version 3.2.0 aswell in 3.3.0!

Now a 14 hour torture test has revealed that there is nothing wrong with my computer, so I'm thinking that either there is a problem in the script used in the "starting new bases" thread, or else there is a problem in WinPFGW. Eitherway, all my work is currently suspended, and if no satisfactoring explanation has been given to me within a 2 or 3 days, I'll not hacitate cancelling all my work.

So Rogue, Gary and anyone else, can you take a look at the files in the attached zip file and come up with an explanation or should I automatically conclude that the WinPFGW tool is not trustworthy and therefor all proofs and low primes should be double checked? So anyone, has an explanation. I may add that during some previous base 955 on the sierp side, i got some log files, where some of the numbers were concluded as: k*955^n+1 is unknown? That was using version 3.2.0, I have not seen this message in the log files using version 3.3.0.

Also doing a triple and comparisation test, 61 PRPs was confirmed primes using WinPGFW version 3.2.0, while they were never seen as anything but composite PRPs using version 3.3.0, you can see the k's that I'm talking about in the pfgw-prime.log file under the version 3.2.0 folder.

Sorry if I sound angry, but I do feel that the work I do, has to be trustworthy and productive, and if we all uses tools that produces composite primes, then our work is in fact a waste. But for now, consider ALL my reservations suspended, while an ongoing torture test is carried out.

If you have any questions, please feel free to ask them, and I'll answer them as good as I can. Again sorry for the tone I'm writing in, but I just hates to waste ressources.

Take care

KEP

[Xentar]

Just tried your attached file.
Is it correct, that you are using the -t parameter?
But you are right. When I use the -t parameter, it actually thinks, every line is composite.
Without this parameter, it says for every line, that it is 3-PRP.

[KEP]

Originally Posted by Xentar

Just tried your attached file.
Is it correct, that you are using the -t parameter?
But you are right. When I use the -t parameter, it actually thinks, every line is composite.
Without this parameter, it says for every line, that it is 3-PRP.

In both 3.2.0 and 3.3.0 PFGW versions I did use following commandline (after finding them all 3-PRP):

pfgw.log -t -lLog.txt

May I ask, what version of WinPFGW did you use? I'm asking because, what really concerns me is the fact that WinPFGW version 3.2.0, did find 61 of the composit primes as Prime, while it previously found all 589 k's prime. I should add, that getting the "is unknown" message, was also when using the -t flag.

Just came to think, can it have something to do with the base? Is there a flaw in the proof method which makes Sierp base 955 test errorneous? I'm here thinking, doesn't the Brillhart-Lehmer proof cover b=955 numbers the appropriate way?

KEP!

[rogue]

This is due to the change in PFGW to use irrational FFTs instead of rational FFTs. The change was made to address problems that would occur during a primality proof for some numbers. The proof would not detect a roundoff or sumout error, yet the test would have an incorrect result.

George knows about the issue (because it is in gwnum). He hopes to tackle it after his current vacation.

My recommendation is to use the -a1 switch if the number is PRP (via a PRP test) and the primality test says that the number is unknown. I know that this is a nuisance for everyone, but switching back to a rational FFT will not resolve the problem. It would only change the numbers that exhibit the problem.

[KEP]

Originally Posted by rogue

This is due to the change in PFGW to use irrational FFTs instead of rational FFTs. The change was made to address problems that would occur during a primality proof for some numbers. The proof would not detect a roundoff or sumout error, yet the test would have an incorrect result.

George knows about the issue (because it is in gwnum). He hopes to tackle it after his current vacation.

My recommendation is to use the -a1 switch if the number is PRP (via a PRP test) and the primality test says that the number is unknown. I know that this is a nuisance for everyone, but switching back to a rational FFT will not resolve the problem. It would only change the numbers that exhibit the problem.

So just to be sure I understand correctly, all k's primes that is verified as primes using WinPFGW version 3.3.0, is SURE to be primes aswell those 589 k's being composites is sure to be composites? As long as the results for the primes produced using WinPFGW version <3.3.0, can be trusted, I guess no harm is done. However. I'm now if it is sure that these primes is composites, going to have to sieve those k's from n=1 to n=2500 to get them. So it will mean a little more work, however I'm ready to accept thath, just as long I can trust that those PRPs being found as primes, using both version 3.2.0 and 3.3.0 is actually primes.

Thanks for explaining, and sure I'll remember to use -a1 next time. Do you think Rogue that it should be nescessary to run a triple check of the primes using -a1 or should they be good to go when they are verified as primes for both version 3.2.0 and 3.3.0?

Regards

KEP

[rogue]

Originally Posted by KEP

So just to be sure I understand correctly, all k's primes that is verified as primes using WinPFGW version 3.3.0, is SURE to be primes aswell those 589 k's being composites is sure to be composites? As long as the results for the primes produced using WinPFGW version <3.3.0, can be trusted, I guess no harm is done. However. I'm now if it is sure that these primes is composites, going to have to sieve those k's from n=1 to n=2500 to get them. So it will mean a little more work, however I'm ready to accept thath, just as long I can trust that those PRPs being found as primes, using both version 3.2.0 and 3.3.0 is actually primes.

Thanks for explaining, and sure I'll remember to use -a1 next time. Do you think Rogue that it should be nescessary to run a triple check of the primes using -a1 or should they be good to go when they are verified as primes for both version 3.2.0 and 3.3.0?

If the number is PRP and the primality test says it is prime (with both 3.2 and 3.3), then it is prime. If one of the following scenarios occurs, I would like to know about it:

1) PRP with both versions, prime with one version, not prime with the other and -a1 with the other still gives unknown.
2) PRP with both versions, prime with neither version. This is regardless if -a1 shows prime or unknown.

[KEP]

Originally Posted by rogue

If the number is PRP and the primality test says it is prime (with both 3.2 and 3.3), then it is prime. If one of the following scenarios occurs, I would like to know about it:

1) PRP with both versions, prime with one version, not prime with the other and -a1 with the other still gives unknown.
2) PRP with both versions, prime with neither version. This is regardless if -a1 shows prime or unknown.

If you download the zip I attached, you can try the 61 PRPs that were found prime by version 3.2.0 but not by version 3.3.0, using -a1

Regarding number 2, 589 k's were PRP for both version 3.2.0 and 3.3.0 and of those, 528 k's with a PRP n wasn't prime on either version. The unknown, wasn't occurring in either version 3.2.0 or 3.3.0 for any of the double- triple- and quadrouple checked k's. But it happened around new years eve. Sadly I doesn't have the log file anymore, but it was running version 3.2.0 and with very small n's, n<=100.

Hope this helps.

KEP

[rogue]

Originally Posted by KEP

If you download the zip I attached, you can try the 61 PRPs that were found prime by version 3.2.0 but not by version 3.3.0, using -a1

Regarding number 2, 589 k's were PRP for both version 3.2.0 and 3.3.0 and of those, 528 k's with a PRP n wasn't prime on either version. The unknown, wasn't occurring in either version 3.2.0 or 3.3.0 for any of the double- triple- and quadrouple checked k's. But it happened around new years eve. Sadly I doesn't have the log file anymore, but it was running version 3.2.0 and with very small n's, n<=100.

I will use those lists to help verify the next release of gwnum with PFGW.

[henryzz]

Originally Posted by KEP

If you download the zip I attached, you can try the 61 PRPs that were found prime by version 3.2.0 but not by version 3.3.0, using -a1

Regarding number 2, 589 k's were PRP for both version 3.2.0 and 3.3.0 and of those, 528 k's with a PRP n wasn't prime on either version. The unknown, wasn't occurring in either version 3.2.0 or 3.3.0 for any of the double- triple- and quadrouple checked k's. But it happened around new years eve. Sadly I doesn't have the log file anymore, but it was running version 3.2.0 and with very small n's, n<=100.

Hope this helps.

KEP

It is possible that some of those prps are actually composite. Could you test the ones that never appear as prime with an old version of pfgw?

[KEP]

Originally Posted by henryzz

It is possible that some of those prps are actually composite. Could you test the ones that never appear as prime with an old version of pfgw?

Well I may look into see how old an version of WinPFGW that I has, but a fact is that all 589 k's turned out prime in the first place, using version 3.2.0, I'm sure that the explanations Rogue has provided, covers the issue regarding the PRP's being prime and then being actual composites, so I think there is no doubt anymore that the 589 k's is actual composites for those n that they are PRP.

So now I has to do a lot of clean-up in order to make sure all tests is carried out on my reservations and hopefully I'll be fully up and running by sometime tomorrow, for all other conjectures than the S955

Thanks for your input and interest.

Regards

KEP