PFGW 4.0.4 (with gwnum v30.10) Released

[wombatman]

Originally Posted by kruoli

Attached is a Linux build. I needed to change GMP from being statically to being dynamically linked. Please give it a try.

Originally Posted by rogue

I have no means to execute this. If someone else can verify that this runs in their environment, then I will put on sourceforge. My main concern is the dynamically linked libraries.

It worked for me on WSL2 (Ubuntu), in that it started running the first line of test00.txt included in the openpfgw tests folder.

[numberMX]

Originally Posted by rogue

I have no means to execute this. If someone else can verify that this runs in their environment, then I will put on sourceforge. My main concern is the dynamically linked libraries.

I tested some numbers on my Ubuntu 20.04 VPS and it seems to be working as expected.

[rogue]

I have updated pfgw to 4.0.5. The only change is gwnum has been updated to 30.11. The Windows build is available on sourceforge. Working on the Mac build

[WraithX]

Does PFGW do prp error checking during all steps of its calculations?

Specifically, I was wondering if it did error checking as described by R. Gerbicz in this thread: https://www.mersenneforum.org/showthread.php?p=624524

And, by "all steps" I mean, it keeps a running rq during all steps and occasionally calculates res%q to compare with rq. (variables taken from the above thread)

[rogue]

Originally Posted by WraithX

Does PFGW do prp error checking during all steps of its calculations?

Specifically, I was wondering if it did error checking as described by R. Gerbicz in this thread: https://www.mersenneforum.org/showthread.php?p=624524

And, by "all steps" I mean, it keeps a running rq during all steps and occasionally calculates res%q to compare with rq. (variables taken from the above thread)

pfgw does error checking, but not exactly what is detailed in that post. gwnum provides some functions that pfgw calls to look for certain types of errors. When one is detected, the assumption is that the chosen FFT size is too aggressive, so it re-starts the test with -a1 (-a2, etc) expecting to have a successful run. Since the FFT size is chosen by gwnum, George has done an incredible job updating gwnum to avoid these when these are reported.

[rebirther]

Is there a way to log start / stop time with an option? I could need this for new base script tests.

[rogue]

Originally Posted by rebirther

Is there a way to log start / stop time with an option? I could need this for new base script tests.

No, but there should be command line options on your OS to do it. On OS X it is "date". On Windows it is "echo %date%-%time%"

[Happy5214]

Originally Posted by rogue

On OS X it is "date".

date is specified by POSIX, so it's the same on Linux too.

[WraithX]

Originally Posted by rogue

pfgw does error checking, but not exactly what is detailed in that post. gwnum provides some functions that pfgw calls to look for certain types of errors. When one is detected, the assumption is that the chosen FFT size is too aggressive, so it re-starts the test with -a1 (-a2, etc) expecting to have a successful run. Since the FFT size is chosen by gwnum, George has done an incredible job updating gwnum to avoid these when these are reported.

According to George, it looks like there was an error in GWNUM starting with versions available from 2020-10-03 which could affect pfgw.
https://mersenneforum.org/showthread...=27905&page=23 Post 244

Which, looking at the https://www.mersenne.org/download/software/ directories, seems like that means 30.4 <= GWNUM <= 30.11.

I'm not sure if you have a list of pfgw <-> gwnum versions, but here is what I found:

pfgw 4.0.1 - GWNUM 29.8
pfgw 4.0.2 - GWNUM 29.8
pfgw 4.0.3 - GWNUM 29.8
pfgw 4.0.4 - GWNUM 30.10
pfgw 4.0.5 - GWNUM 30.11

You may want to pull 4.0.4 and 4.0.5 and release a new 4.0.6 with a different GWNUM version (maybe 30.3 or 30.12)?

Also, could we add Gerbicz error checking as an option? I'm looking at the code now to see if I may be able to help add this feature, but since I'm new to both it may take a while.

[rogue]

Originally Posted by WraithX

According to George, it looks like there was an error in GWNUM starting with versions available from 2020-10-03 which could affect pfgw.
https://mersenneforum.org/showthread...=27905&page=23 Post 244

Which, looking at the https://www.mersenne.org/download/software/ directories, seems like that means 30.4 <= GWNUM <= 30.11.

I'm not sure if you have a list of pfgw <-> gwnum versions, but here is what I found:

pfgw 4.0.1 - GWNUM 29.8
pfgw 4.0.2 - GWNUM 29.8
pfgw 4.0.3 - GWNUM 29.8
pfgw 4.0.4 - GWNUM 30.10
pfgw 4.0.5 - GWNUM 30.11

You may want to pull 4.0.4 and 4.0.5 and release a new 4.0.6 with a different GWNUM version (maybe 30.3 or 30.12)?

Also, could we add Gerbicz error checking as an option? I'm looking at the code now to see if I may be able to help add this feature, but since I'm new to both it may take a while.

I was not aware of that. It isn't clear if this was fixed in 30.12.

I do not know what is involved with Gerbicz error checking so I don't know if it would be easy to code. Other programs support it so it isn't high priority.

[WraithX]

George mentions on the previous page that 30.12 beta 1 fixed this error. You can see it in post 235 of this thread:
https://mersenneforum.org/showthread...=27905&page=22

Here is his quote:

30.12 build 1

PRE-BETA software!

Since last build:
-- rare gwnum radix conversion bug fixed for LLR/PFGW
-- bug in waking up thread to upload proofs fixed
-- changed default settings for a faster stage 2 (at least on my 2 machines)
-- James' timed CoresPerTest setting might work

And in post 240 he talks about 30.12 looking stable for prp and ecm:

You should be OK using 30.12. I've been using 30.12 for 2 weeks (PRP and ECM) without any issues.