PFGW 3.2.0 has been Released

[TimSorbet]

I don't run Mac or Linux so I'm not interested. Others might be.

Originally Posted by henryzz

If it will do everything. I don't use the windows one currently because AFAIK it only does prp tests and i don't know how to set things like -f30.

You set all that in the box labeled 'Standard "PFGW compatible" command line'. Think of that box as the command line arguments (supplemented by the menu options), not just a "put work file name here" box. So you could do something like this: "work.txt -f30 -tp" and it will do everything implied by those command line arguments.

[rogue]

Originally Posted by henryzz

Another thing is when my pc is turned off pfgw is particularly good at losing where it is upto. LLR 3.7 has done that once for me but it would be nice to be able to trust it like LLR. This is on windows and mainly with 3.2.3 and earlier i think.

I don't understand. PFGW keeps track of its current progress with the pfgw.ini file. It creates pfr files during tests so that it can restart in the middle when it gets restarted. You might need to do a few iterations, but PFGW would be wasting time to update that pfr file after every iteration.

[henryzz]

Originally Posted by rogue

I don't understand. PFGW keeps track of its current progress with the pfgw.ini file. It creates pfr files during tests so that it can restart in the middle when it gets restarted. You might need to do a few iterations, but PFGW would be wasting time to update that pfr file after every iteration.

I should have said not turned off cleanly.
I have always presumed that it was turned off exactly when pfgw.ini was being written to. This has happened several times and i am not certain that all the tests have been really short so pfgw.ini shouldn't have been changed that often. Is pfgw.ini changed whenever a checkpoint file is produced?

[ET_]

Originally Posted by henryzz

I should have said not turned off cleanly.
I have always presumed that it was turned off exactly when pfgw.ini was being written to. This has happened several times and i am not certain that all the tests have been really short so pfgw.ini shouldn't have been changed that often. Is pfgw.ini changed whenever a checkpoint file is produced?

Yes, AFAIK. I had the same problem, and losty 60% of my work during an electric outage.

Luigi

[henryzz]

Originally Posted by ET_

Yes, AFAIK. I had the same problem, and losty 60% of my work during an electric outage.

Luigi

Done that.

[rogue]

Originally Posted by henryzz

I should have said not turned off cleanly.
I have always presumed that it was turned off exactly when pfgw.ini was being written to. This has happened several times and i am not certain that all the tests have been really short so pfgw.ini shouldn't have been changed that often. Is pfgw.ini changed whenever a checkpoint file is produced?

I will look into the code to see how often the ini file is written. The ini file should be independent written independently of the pfr file.

[rogue]

You can d/l the files from http://sourceforge.net/projects/openpfgw/files/.

At this time I only have the Windows build available, but hope to have the Mac and Linux ones available in the next day or so.

Here is a summary of the changes:

• Rolled back changes from 3.3.1 because they resulted in memory leaks in WinPFGW. Used a different method to force display of test result when using -q.
• Re-enabled Windows code to check memory leaks with debug builds.
• Added memory leak logic to WinPFGW.
• Fixed all known memory leaks in PFGW. These memory leaks have existed since 1.x.
• Fixed most of the other memory leaks in WinPFGW. These leaks occur when PFGW is terminated and not during execution of PRP/primality tests.
• Changed documentation for -h to match functionality of PFGW. -h now requires an argument. Previously the argument was optional and would default to pfgw.txt.

The memory leak detection code is built into debug builds only, not releases.

[rogue]

Originally Posted by rogue

You can d/l the files from http://sourceforge.net/projects/openpfgw/files/.

At this time I only have the Windows build available, but hope to have the Mac and Linux ones available in the next day or so.

Here is a summary of the changes:

• Rolled back changes from 3.3.1 because they resulted in memory leaks in WinPFGW. Used a different method to force display of test result when using -q.
• Re-enabled Windows code to check memory leaks with debug builds.
• Added memory leak logic to WinPFGW.
• Fixed all known memory leaks in PFGW. These memory leaks have existed since 1.x.
• Fixed most of the other memory leaks in WinPFGW. These leaks occur when PFGW is terminated and not during execution of PRP/primality tests.
• Changed documentation for -h to match functionality of PFGW. -h now requires an argument. Previously the argument was optional and would default to pfgw.txt.

The memory leak detection code is built into debug builds only, not releases.

The Linux and MacIntel builds have been updated at the aforementioned link.

[rogue]

I have posted Windows binaries here, http://sourceforge.net/projects/openpfgw/files/. MacIntel and Linux binaries will follow in the next day or so.

The major change in this release is that it has been updated to use gwnum 25.14, which addresses the following issues:

• Gwnum would lose the /d in some (k*b^n+c)/d cases. This happened primarily in cases where the number was between 300 and 350 bits.
• The final conversion from gwnum to binary could fail in cases where generic reduction was used. The larger the number the less likely the bug would occur.
• Zero padded FFTs of length 80 and 112 could fail.
• More conservative in selecting an FFT length for non-base-2 cases.

This release also goes back to using rational FFTs, which are slightly faster than irrational FFTs.

With these changes to gwnum, there will be fewer roundoff errors with PFGW. These changes also address primality tests that silently fail. "Silently fail" refers to tests that do not trigger roundoff errors, yet have an incorrect result. It is highly recommended to update your clients to this release.

[Harvey563]

Mark. I'll get going on the Linux build!!

Steven

[rogue]

Originally Posted by Harvey563

Mark. I'll get going on the Linux build!!

Steven

Thank you.

Make sure you get the latest gwnum from ftp://mersenne.org/gimps/source2514.zip before building.