PFGW 3.1.0 has been Released
 

I have posted the latest Windows and MacIntel distributions at these links:

[url]http://openpfgw.svn.sourceforge.net/viewvc/openpfgw/pfgw_win_3.1_20090708.zip[/url]
[url]http://openpfgw.svn.sourceforge.net/viewvc/openpfgw/pfgw_mac_3.1_20090708.zip[/url]

This marks the first release of PFGW for MacIntel.

Enhancements to: v3.1.0 RC 1b[list][*]Updated external version to meet intenal version.[*]Updated to v25.11 of George Woltman's gwnum library. [*]Use new modular reduction routines in gwnum for k*b^n+/-c forms. This is about twice as fast as prior releases when k > 1 and almost 6 times as fast when k = 1 and b > 2. GFNs already use this same modular reductino code. [*]Removed special GFN PRP code as it is no longer necessary due to new modular reduction code for k*b^n+/-c forms. [*]Set default priority class to BELOW_NORMAL (instead of NORMAL) on Windows. [*]Set priority to 20 (low) on *nix and MacIntel.[*]Increased limits for factorials to 1,000,000. [*]Increased limits for primorials to 20,000,000. [*]Modified -r switch to act as a boolean. Using it will force PFGW to do roundoff checking for all iterations of all tests. [*]Enhanced error checking so that PFGW can conditionally do MAXERR testing on individual tests or specific iterations of tests. In this release PFGW will do MAXERR checking on the first and last 50 itererations of each test and every 128th iteration of each test. It can test all iterations of each test if the -r switch is used or if the number being testing is within 2% of the limit of the chosen FFT size. This will be much more in-line with how Prime95 does MAXERR testing.[*]GFN factoring now checks for ROUNDOFF, SUMOUT, and MAXERR conditions so that it can be aborted if a problem is detected. This means that PFGW will now tell the user that they must use the -a switch when a problem is detected. [*]Add call to gwset_square_carefully_count() after creating the modulus so that gwnum can use "safe" squaring on the first few iterations of PRP tests or GFN factoring. This will significantly reduce the likelihood that the -a switch will be needed. [*]Based upon George's recommendation (due to the improved error checking), MAXERR is now set to 0.45 instead of 0.40. [*]Call new gwinit2() function so that PFGW can verify that it is linked against the correct version of the gwnum library and so that it can verify that PFGW uses the same compiler switches that were used to build gwnum.[/list]I am not aware of any issues with this release, but I only have limited resources for my testing. For example, I cannot test against P3 (or older), Centrino, or AMD CPUs.

The two biggest changes of interest to casual users is that PFGW should now be faster than LLR for bases that are not powers of 2. I suspect Jean Penne will make the appropriate changes to LLR to take advantage of the same modular code that PFGW is now using. I have not compared base 2 tests between the two programs. The other is that the -a switch is not required for GFN factoring and that PFGW will now tell you if an error occurred during GFN factoring.

Many thanks to George for his enhancements to gwnum that were done specifically for PFGW.

I do have a volunteer for building on linux, so hopefully I can make a linux distribution available in the near future.

I will be on vacation for a few days, so please be patient if you run into any issues that need to be addressed.

Enjoy,
Mark

A couple questions:

-For non-power-of-2 bases, for which PFGW now does PRP tests faster than LLR, does PFGW provide a residual of the same length as LLR/Phrot? Or does it still only give a shorter one, like older versions did?

-When will a new version of the PRPnet client be released to use PFGW by default instead of LLR for non-power-of-2 PRP tests? :grin:

[QUOTE=mdettweiler;180269]A couple questions:

-For non-power-of-2 bases, for which PFGW now does PRP tests faster than LLR, does PFGW provide a residual of the same length as LLR/Phrot? Or does it still only give a shorter one, like older versions did?

-When will a new version of the PRPnet client be released to use PFGW by default instead of LLR for non-power-of-2 PRP tests? :grin:[/QUOTE]

PFGW how has 16 character residues, i.e. it adds leading zeros. If using PRPNet 2.2.x, that shouldn't matter as it will ignore leading zeroes when comparing residues.

I don't have an answer for the second question. I could make the change fairly easily, but I expect Jean to modify LLR to take advantage of George's new code. I do not know when that will happen. I haven't heard from Jean, but am willing to help him with the changes when he is ready (presuming he needs any help).

[quote=rogue;180277]PFGW how has 16 character residues, i.e. it adds leading zeros. If using PRPNet 2.2.x, that shouldn't matter as it will ignore leading zeroes when comparing residues.

I don't have an answer for the second question. I could make the change fairly easily, but I expect Jean to modify LLR to take advantage of George's new code. I do not know when that will happen. I haven't heard from Jean, but am willing to help him with the changes when he is ready (presuming he needs any help).[/quote]
Oh, I see. Okay, I guess that works fine then. At this time having a shorter residue should still work fine for CRUS, though not for NPLB since there we have our database handle comparisons between firstpass and doublecheck residues. But then, at NPLB we only do base 2 work, so thus it's somewhat of a moot point. :smile:

At any rate, yes, I agree that it would probably be better to simply wait for the updated version of LLR (assuming it comes out soon, and the changes are not delayed until version 3.7.1d which I hear has been in the works for a while and hasn't yet materialized) rather than updating PRPnet. That way the whole thing with the residues should be no big deal at all.

I've done some benchmarks to compare LLR 3.7.1c, Phrot 0.70, PFGW 3.1.0, and Prime95 25.11 on a Riesel base 3 PRP test:
[code]
17589196*3^78001-1 is composite: RES64: [229FF2F0D0593F25] (33.5454s+0.0024s)
17589196*3^78001-1 is not prime. RES64: E29FF2F0D0593F25 OLD64: A7DFD8D2710BBD6C Time : 93.840 sec.
17589196*3^78001-1 is composite LLR64=e29ff2f0d0593f25. (e=0.09375 ([EMAIL="0.160502~4.7607e-016@0.000"]0.160502~4.7607e-016@0.000[/EMAIL]) t=77.53s)
17589196*3^78001-1 is not prime. RES64: E29FF2F0D0593F25. Wd1: 41B08704,00000000[/code]
[I]Note: even though Prime95 does not record times, it was about the same speed as PFGW, as expected.[/I]

I'm surprised at just how much of a speed boost there was--the programs utilizing the new gwnum 25.11 (PFGW and Prime95) all had about a 64% speed increase over LLR 3.7.1c (i.e. gwnum 24.14). Compared to Phrot, there was a 57% speed increase.

Interestingly enough, I discovered that PFGW *does* give full 16 character residues now, and not just by zero-padding a smaller one. However, quite oddly, the PFGW residue matches all of the others, except for the first character! And it's reproducible, too, so this is not just some exceedingly improbable fluke.

I'm going to try running some further tests with PFGW to see if the residue goof appears in other numbers as well.

Meanwhile, for people testing non-power-of-2 k*b^n+-c numbers right now, I would recommend using Prime95 v25.11, at least until an updated LLR comes out. Prime95 has all the same speed boosts in it as PFGW, yet it doesn't suffer from the weird residue glitch. For instructions on how to use Prime95 to do PRP tests, see [url=http://www.mersenneforum.org/showpost.php?p=181108&postcount=2]this post[/url]. (The last part about Prime95's speed relative to LLR can be ignored, since it relates specifically to base 2 numbers, which the speed boosts do not affect.)

[QUOTE=mdettweiler;181123]I've done some benchmarks to compare LLR 3.7.1c, Phrot 0.70, PFGW 3.1.0, and Prime95 25.11 on a Riesel base 3 PRP test:
[code]
17589196*3^78001-1 is composite: RES64: [229FF2F0D0593F25] (33.5454s+0.0024s)
17589196*3^78001-1 is not prime. RES64: E29FF2F0D0593F25 OLD64: A7DFD8D2710BBD6C Time : 93.840 sec.
17589196*3^78001-1 is composite LLR64=e29ff2f0d0593f25. (e=0.09375 ([EMAIL="0.160502~4.7607e-016@0.000"]0.160502~4.7607e-016@0.000[/EMAIL]) t=77.53s)
17589196*3^78001-1 is not prime. RES64: E29FF2F0D0593F25. Wd1: 41B08704,00000000[/code]
[I]Note: even though Prime95 does not record times, it was about the same speed as PFGW, as expected.[/I]

I'm surprised at just how much of a speed boost there was--the programs utilizing the new gwnum 25.11 (PFGW and Prime95) all had about a 64% speed increase over LLR 3.7.1c (i.e. gwnum 24.14). Compared to Phrot, there was a 57% speed increase.

Interestingly enough, I discovered that PFGW *does* give full 16 character residues now, and not just by zero-padding a smaller one. However, quite oddly, the PFGW residue matches all of the others, except for the first character! And it's reproducible, too, so this is not just some exceedingly improbable fluke.

I'm going to try running some further tests with PFGW to see if the residue goof appears in other numbers as well.

Meanwhile, for people testing non-power-of-2 k*b^n+-c numbers right now, I would recommend using Prime95 v25.11, at least until an updated LLR comes out. Prime95 has all the same speed boosts in it as PFGW, yet it doesn't suffer from the weird residue glitch. For instructions on how to use Prime95 to do PRP tests, see [url=http://www.mersenneforum.org/showpost.php?p=181108&postcount=2]this post[/url]. (The last part about Prime95's speed relative to LLR can be ignored, since it relates specifically to base 2 numbers, which the speed boosts do not affect.)[/QUOTE]

Don't worry too much about the residue "glitch" at this time. PFGW residues are 62-bit, not 64-bit, thus the difference. Since I am the "owner" of PFGW now, I will look into it and see what I can do to support 64-bit residues. Chances of a bad test where the lower 62 bits of the residue match those of a good test are extremely small because PFGW does all sorts of error checking to ensure that the test has not failed along the way.

BTW, PRPNet ignores the first non-zero character because it knows about this limitation with PFGW.

My recommendation is still to use PFGW since it supports ABC and NewPGen input files.

[QUOTE=rogue;181139]Don't worry too much about the residue "glitch" at this time. PFGW residues are 62-bit, not 64-bit, thus the difference. Since I am the "owner" of PFGW now, I will look into it and see what I can do to support 64-bit residues. Chances of a bad test where the lower 62 bits of the residue match those of a good test are extremely small because PFGW does all sorts of error checking to ensure that the test has not failed along the way.[/QUOTE]

The next release will have 64-bit residues. I made a change today and it appears to be working correctly.

Would it be possible for PFGW to use Prime95's P-1 code?
If it could then output factors in srsieve's factors.txt format that would be brill.

[QUOTE=rogue;181164]The next release will have 64-bit residues. I made a change today and it appears to be working correctly.[/QUOTE]

Waiting for the new release to update Fermatsearch download page. Thanks Mark!

Luigi

[QUOTE=henryzz;181544]Would it be possible for PFGW to use Prime95's P-1 code?
If it could then output factors in srsieve's factors.txt format that would be brill.[/QUOTE]

Possibly, but why not us Prime95 or GMP-ECM? IIRC GMP-ECM can link with gwnum to assist in factoring.

[quote=rogue;181563]Possibly, but why not us Prime95 or GMP-ECM? IIRC GMP-ECM can link with gwnum to assist in factoring.[/quote]
both prime95 and gmp-ecm dont support any of the usual formats for primality testing
also from memory compiling gmp-ecm with gwnum is a massive exercise
both programs also output in convoluted ways which would require a script to extract the factors

why waste time having a complicated script when it could be done even easier by pfgw?

[quote=rogue;181164]The next release will have 64-bit residues. I made a change today and it appears to be working correctly.[/quote]
Just curious, when will this next release be available? Is the residue fix ready now, and the release waiting for something else?

[QUOTE=mdettweiler;181600] and the release waiting for something else?[/QUOTE]

I'm tracking down several problems with gwnum's selection of proper FFT size.

[quote=Prime95;181604]I'm tracking down several problems with gwnum's selection of proper FFT size.[/quote]
Ah, I see. Are the problems critical, or is a (automatically corrected) FFT roundoff error the worst that could possibly happen? If so, then Mark, would it be possible to post a copy of the modified PFGW 3.1.0 that produces correct 64-bit residues, so that it can be utilized in the meantime? :smile:

Hi

For some reason I can't open the zip files using winrar or winzip 12.1 on a winxp machine. The zip files appear to be corrupted (according to the SW). Would it be possible to post these files in another format or something?

[QUOTE=MrOzzy;181953]Hi

For some reason I can't open the zip files using winrar or winzip 12.1 on a winxp machine. The zip files appear to be corrupted (according to the SW). Would it be possible to post these files in another format or something?[/QUOTE]

I have posted a copy [URL="http://home.roadrunner.com/~mrodenkirch/pfgw_win_3.1_20090708.zip"]here[/URL].

I would like to know if this problem is specific to any browsers. I know that Safari and Firefox d/l the file correctly on WinXP. It could be specific to IE or it could be specific to WinZip. AFAICT, SVN correct detects the file as binary. BTW, what is the size of the file after you d/l it?

when will a linux(64) build be arriving?

[quote=rogue;181980]I have posted a copy [URL="http://home.roadrunner.com/~mrodenkirch/pfgw_win_3.1_20090708.zip"]here[/URL].

I would like to know if this problem is specific to any browsers. I know that Safari and Firefox d/l the file correctly on WinXP. It could be specific to IE or it could be specific to WinZip. AFAICT, SVN correct detects the file as binary. BTW, what is the size of the file after you d/l it?[/quote]

I used IE8 to download the files.
The exact size of the file: size: 3.152.332 bytes, size on disk: 3.153.920 bytes.

This other download works fine by the way.

[QUOTE=MrOzzy;182038]I used IE8 to download the files.
The exact size of the file: size: 3.152.332 bytes, size on disk: 3.153.920 bytes.

This other download works fine by the way.[/QUOTE]

I wonder if there is something odd with SVN that prevents the browser from detecting the correct file type. Could you try with another browser and tell me if it works correctly on your computer?

[QUOTE=henryzz;182032]when will a linux(64) build be arriving?[/QUOTE]

Steven Harvey has built one (32-bit) and is testing it. I expect 3.2 to have an official linux release. I hope to have 3.2 ready in early August.

[quote=rogue;182059]I wonder if there is something odd with SVN that prevents the browser from detecting the correct file type. Could you try with another browser and tell me if it works correctly on your computer?[/quote]

I used google chrome to download the orignal file. I could open it without problems.

[QUOTE=MrOzzy;182062]I used google chrome to download the orignal file. I could open it without problems.[/QUOTE]

That seems to point a finger at IE 8. I will recommend that people avoid using IE when d/l'ing the file.

[quote=rogue;182088]That seems to point a finger at IE 8. I will recommend that people avoid using IE when d/l'ing the file.[/quote]
I didn't have a problem downloading it with IE 7, so maybe the problem is only with IE 8.

(P.S.: Could you possibly post a binary for the version of 3.1.0 that you fixed to produce true 64-bit residues? Even without the FFT library bugs fixed just yet, it still would be quite handy to have that available. :smile:)

I have IE 8 and have results similar to MrOzzy when using IE 8, works fine in FF 3.5. (I don't have WinZip or WinRar installed, just 7-Zip, but the downloaded .zip does not work correctly) More specifically: it downloads the first link in this thread (I'm assuming that's the one MrOzzy was trying) without any apparent problems, but when I open it in 7-Zip it only lists one file with the same name as the archive and no file extension (e.g. if I name it pfgw.zip the file is "pfgw"). If extracted and ran as an .exe, the command window says "Program too big to fit in memory". When downloaded with Firefox it works fine.

[QUOTE=mdettweiler;182091]I didn't have a problem downloading it with IE 7, so maybe the problem is only with IE 8.

(P.S.: Could you possibly post a binary for the version of 3.1.0 that you fixed to produce true 64-bit residues? Even without the FFT library bugs fixed just yet, it still would be quite handy to have that available. :smile:)[/QUOTE]

Sorry, but you will have to wait for 3.2.0.

I confirm this "bug" using IE8. It works OK with Firefox.