PFGW latest well-tested version

[gd_barnes]

Originally Posted by rogue

Sorry, but I did not get a Linux build for 3.2.7. Fortunately no script changes are necessary for 3.3.0.

There is one known issue. It only exists in WinPFGW and is cosmetic. The "Line in file" field is not getting updated consistently. I have a patched version ready, but I am waiting for additional testing from others before I post it. If any bugs are revealed, I will make sure that those get fixed and get a new release out there.

OK, thanks. No problem. I'll use 3.3.0 for testing script changes. I'll probably start working on them tomorrow. Then once you release 3.3.1 (or whatever), I'll run some quick tests with it and hopefully will be able to update the 1st post here with a new latest well-tested version.

[Xentar]

Originally Posted by gd_barnes

If testing more than one k:
1. Run srsieve to some small P-limit and have it write out the file in -a format. I use P=100e6 for the P-limit.
2. Use the output from #1 and run sr2sieve to your optimum depth. It will write out a file of factors called factors.txt. All you need is the P-limit and file name.
3. Use srfile to remove the factors in #2 from the file in #1 and write it out in -w or -G format.
4. If running the conjectures here, be sure and change the header to use the stop-on-prime option before beginning PFGW testing.

That's exactly, what I am doing. So, there is no easier way, without converting the file format.

Thank you for the explanation.

[gd_barnes]

Mark,

I am getting quite a few roundoff errors in PFGW 3.2.7.

I did quite a bit of extra comparison testing between versions 3.2.3 and 3.2.7 in an attempt to help you ultimately eliminate the errors.

Here are some roundoff errors that I got in version 3.2.3 (not originally tested in 3.2.7):
1780*112^19007+1
1696*112^19080+1
1780*112^19118+1
1696*112^19136+1
1696*112^19172+1

I subsequently tested these in 3.2.7 and there were no roundoff errors. That's a good thing.

Here are some roundoff errors that I got in version 3.2.7 (not originally tested in 3.2.3):
1379*138^9373+1
9000*93^4798+1
9844*93^6369+1
8224*93^9451+1
7868*93^9500+1
6748*93^9571+1
6748*93^9603+1
344*161^15982-1
378*161^18855-1

I subsequently tested these in 3.2.3 and found that they all had the same error EXCEPT one; the very last one: 378*161^18855-1, which tested correctly. That's not a good thing. confused:

The first test where 3.2.7 corrected all of the 3.2.3 errors is what I would expect.

I was taken aback by the second test. An error that occurred in 3.2.7 did NOT occur in 3.2.3!

My question is: Does this mean that new roundoff errors are being introduced?

I've attached many different files from my testing. Naming definitions:
input-errs-3.2.x = Input files of tests with the PFGW version # that produced errors.

pfgw.out-3.2.x-errs = The pfgw.out (regular results) file for the specified PFGW version #.

pfgw.out-3.2.x-errs-run-3.2.y = The pfgw.out file for errors produced in 3.2.x ran in 3.2.y.
[Example: pfgw.out-3.2.3-errs-run-3.2.7 = These were originally 3.2.3 errors but I subsequently ran them in 3.2.7 to verify that the errors were corrected. (In this case, since it's a newer PFGW version, it correctly came up with no errors. That is it shows that all tests are composite.)]

pfgw_err-3.2.x-errs = Self-explanatory. The original pfgw_err file where the errors came to light.

The major concern is file pfgw.out-3.2.7-errs-run-3.2.3.txt. This is the regular resutls file for 3.2.7 errors ran in version 3.2.3. If you look at the very last line, you'll see:
378*161^18855-1 is composite: RES64: [6221E6A7DC82F65B] (103.0717s+0.0029s)

This tells me that potentially a new error was introduced in version 3.2.7 that wasn't in 3.2.3.

One final note: When I used the -a1 switch on all of these, it ran a good test and showed them all to be composite.

I'll download 3.3.0 in a little while and start using it for testing. I won't be looking for roundoff errors...just that it runs fine. If so, I'll update the 1st post here with both the Windows and Linux versions of it. In a little while, I'll also look to start updating the new bases script for the scripting language updates introduced in 3.2.7.

Possible suggestion: If there is a roundoff error, would it make sense to have PFGW automatically run the same test a 2nd time? Perhaps on the 2nd test, have it run the same code that is executed when the -a1 switch is used.

Question: What about always testing using the -a1 switch? Would that make the tests take much longer?


Gary

[henryzz]

Originally Posted by gd_barnes

Possible suggestion: If there is a roundoff error, would it make sense to have PFGW automatically run the same test a 2nd time? Perhaps on the 2nd test, have it run the same code that is executed when the -a1 switch is used.

AFAIK thats the changes in 3.3

[gd_barnes]

lol, I just downloaded 3.3.0 and read the release notes. You did exactly what I suggested in the last para. on the previous post. I subsequently reran the 3.2.7 errors through it and they all tested great!

The cool part is that the error didn't show up in pfgw.out. It's nice to have a good clean results file.

Obviously you can ignore my previous post. I thought about deleting it but I figured it might be good for reference if any problems crop up in the future.

By by roundoff errors (well, at least on a 2nd test anyway).

Nice work!


Gary

[gd_barnes]

Originally Posted by henryzz

AFAIK thats the changes in 3.3

Your post came through while I was typing mine. I had already concluded what you wrote. lol

I have now posted links to all 3 versions of PFGW 3.3.0 in the 1st post here.

I think we have a keeper.

[gd_barnes]

There seems to be a small quirk/bug introduced with PFGW 3.2.7:

It appears that PFGW is automatically running an extra primality test on small tests that are found to be trivially prime when using the -f factoring switch. Here is an example from the pfgw.out file:

6*172^1+1 is trivially prime!
6*172^1+1 trivially factors prime!: 1033

While I don't think this causes a problem, per se, it makes for very irritating gui screen output. I like to keep the "output verbose screen" set to "screen normal" to see PRP's as they are kicked out so that I can see at a glance where testing is at. But with this issue, 100's of messages continue scrolling out that show "xx*xx^xx+1 is trivially prime!" making it difficult to see where it is at and slowing down processing slightly.

Can this be fixed?

I confirmed that the issue did not exist in version 3.2.3.

I've just about finished my new script changes for 3.2.7/3.3.0 and thought I had a bug in my code for quite a while.

One more thing that has been a small issue since release 3.1.0: When you do a mouse-over of WinPFGW.exe, it still shows versioin 3.1.0.0 in the little white box. I didn't check if it does that in the Linux version.


Gary

[rogue]

Originally Posted by gd_barnes

There seems to be a small quirk/bug introduced with PFGW 3.2.7:

It appears that PFGW is automatically running an extra primality test on small tests that are found to be trivially prime when using the -f factoring switch. Here is an example from the pfgw.out file:

6*172^1+1 is trivially prime!
6*172^1+1 trivially factors prime!: 1033

While I don't think this causes a problem, per se, it makes for very irritating gui screen output. I like to keep the "output verbose screen" set to "screen normal" to see PRP's as they are kicked out so that I can see at a glance where testing is at. But with this issue, 100's of messages continue scrolling out that show "xx*xx^xx+1 is trivially prime!" making it difficult to see where it is at and slowing down processing slightly.

Can this be fixed?

I confirmed that the issue did not exist in version 3.2.3.

One more thing that has been a small issue since release 3.1.0: When you do a mouse-over of WinPFGW.exe, it still shows versioin 3.1.0.0 in the little white box. I didn't check if it does that in the Linux version.

I will change the message in the next release. I have no other changes accumulated for that release, so it might be a while before there is a 3.3.2.

The last issue was fixed in 3.3.0.

Regarding the roundoff/sumout errors. I modified PFGW to use an irrational FFT because there were cases that tests would not trigger a roundoff/sumout error, yet would not have correct results unless using the -a1 switch. This was a recommendation from George. This results in some tests getting roundoff/sumout errors that did not get them before (even though they had correct output without -a1 before). The more important thing is guaranteeing that the if no error is triggered, then one knows that the output is correct.

BTW, -a1 will slow the test down by a few percent. It can vary from number to number based upon the size of the number being tested.

[Mini-Geek]

Originally Posted by Mini-Geek

Out of nearly 2.5 million primes verified for a part of Riesel base 3, these 6 all return PRP, return composite with -tp but no -a1, and return prime with -tp and -a1:

800157112*3^64-1
800829524*3^47-1
801245282*3^50-1
802324048*3^490-1
802829672*3^59-1
804875072*3^71-1

I doubt that anybody cares or that anything needs to be done, just felt like reporting that little fact.

If I understand correctly, the new version should've stopped silent failures such as this, but it doesn't.

PFGW Version 3.3.1.20100111.Win_Dev [GWNUM 25.13]

Primality testing 800157112*3^64-1 [N+1, Brillhart-Lehmer-Selfridge]
Running N+1 test using discriminant 7, base 1+sqrt(7)
Special modular reduction using generic reduction x87 FFT length 32 on 800157112*3^64-1
800157112*3^64-1 is composite (0.0318s+0.0001s)
Primality testing 800829524*3^47-1 [N+1, Brillhart-Lehmer-Selfridge]
Running N+1 test using discriminant 5, base 1+sqrt(5)
Special modular reduction using generic reduction x87 FFT length 32 on 800829524*3^47-1
800829524*3^47-1 is composite (0.0021s+0.0001s)
Primality testing 801245282*3^50-1 [N+1, Brillhart-Lehmer-Selfridge]
Running N+1 test using discriminant 3, base 3+sqrt(3)
Special modular reduction using generic reduction x87 FFT length 32 on 801245282*3^50-1
801245282*3^50-1 is composite (4.9667s+0.0001s)
Primality testing 802324048*3^490-1 [N+1, Brillhart-Lehmer-Selfridge]
Running N+1 test using discriminant 17, base 1+sqrt(17)
Special modular reduction using zero-padded FFT length 80 on 802324048*3^490-1
802324048*3^490-1 is composite (0.0154s+0.0001s)
Primality testing 802829672*3^59-1 [N+1, Brillhart-Lehmer-Selfridge]
Running N+1 test using discriminant 5, base 1+sqrt(5)
Special modular reduction using generic reduction x87 FFT length 32 on 802829672*3^59-1
802829672*3^59-1 is composite (0.0023s+0.0001s)
Primality testing 804875072*3^71-1 [N+1, Brillhart-Lehmer-Selfridge]
Running N+1 test using discriminant 5, base 1+sqrt(5)
Special modular reduction using generic reduction x87 FFT length 32 on 804875072*3^71-1
804875072*3^71-1 is composite (0.0023s+0.0001s)

Done.

[rogue]

Originally Posted by Mini-Geek

If I understand correctly, the new version should've stopped silent failures such as this, but it doesn't.

PFGW Version 3.3.1.20100111.Win_Dev [GWNUM 25.13]

Primality testing 800157112*3^64-1 [N+1, Brillhart-Lehmer-Selfridge]
Running N+1 test using discriminant 7, base 1+sqrt(7)
Special modular reduction using generic reduction x87 FFT length 32 on 800157112*3^64-1
800157112*3^64-1 is composite (0.0318s+0.0001s)
Primality testing 800829524*3^47-1 [N+1, Brillhart-Lehmer-Selfridge]
Running N+1 test using discriminant 5, base 1+sqrt(5)
Special modular reduction using generic reduction x87 FFT length 32 on 800829524*3^47-1
800829524*3^47-1 is composite (0.0021s+0.0001s)
Primality testing 801245282*3^50-1 [N+1, Brillhart-Lehmer-Selfridge]
Running N+1 test using discriminant 3, base 3+sqrt(3)
Special modular reduction using generic reduction x87 FFT length 32 on 801245282*3^50-1
801245282*3^50-1 is composite (4.9667s+0.0001s)
Primality testing 802324048*3^490-1 [N+1, Brillhart-Lehmer-Selfridge]
Running N+1 test using discriminant 17, base 1+sqrt(17)
Special modular reduction using zero-padded FFT length 80 on 802324048*3^490-1
802324048*3^490-1 is composite (0.0154s+0.0001s)
Primality testing 802829672*3^59-1 [N+1, Brillhart-Lehmer-Selfridge]
Running N+1 test using discriminant 5, base 1+sqrt(5)
Special modular reduction using generic reduction x87 FFT length 32 on 802829672*3^59-1
802829672*3^59-1 is composite (0.0023s+0.0001s)
Primality testing 804875072*3^71-1 [N+1, Brillhart-Lehmer-Selfridge]
Running N+1 test using discriminant 5, base 1+sqrt(5)
Special modular reduction using generic reduction x87 FFT length 32 on 804875072*3^71-1
804875072*3^71-1 is composite (0.0023s+0.0001s)

Done.

It should have, but obviously doesn't. This is a problem with gwnum that I cannot fix. This might have to wait until gwnum 26.x before it can be resolved. I'll see if George is able to spend time on it. Note that I do not know the conditions that trigger this problem, although it seems to only happen with small n.

[Mini-Geek]

Originally Posted by rogue

It should have, but obviously doesn't. This is a problem with gwnum that I cannot fix. This might have to wait until gwnum 26.x before it can be resolved. I'll see if George is able to spend time on it. Note that I do not know the conditions that trigger this problem, although it seems to only happen with small n.

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?