PFGW 3.2.1 has been released
 

You can d/l the Windows and MacIntel builds from these links. I will post a link for the linux build when it is ready.

[URL="http://openpfgw.svn.sourceforge.net/viewvc/openpfgw/pfgw_win_3.2.1_20090809.zip?view=log"]PFGW for Windows[/URL]
[URL="http://openpfgw.svn.sourceforge.net/viewvc/openpfgw/pfgw_mac_3.2.1_20090809.zip?view=log"]PFGW for MacIntel[/URL]

Please do not use IE to get these files. IE seems to want to d/l the files as text instead of binary which will mean that you cannot unzip them after d/ling as the zip archive will be corrupted. You should use a better browser such as Safari or FireFox.

Enhancements to: v3.2.1 RC 1d
[list][*]Built with updated 25.12 gwnum library.[*]Fixed ROUNDOFF error during primality test by using carefully routines during first and last 30 iterations.[*]Verify that values do not exceed limits so that special modular arithmatic can be used. For example k must be less than 1e53.[*]Verify that d (of (k*b^n+c)/d) divides evenly otherwise special modular arithmatic cannot be used.[*]Add check for SUMOUT error during primality test.[*]Fixed a bug intorduced in 3.1 that prevented PFGW from finding Fermat factors.[*]Renamed this file to release_notes.txt. Removed RELNOTES.[/list]
Thanks again to testers for finding many of these bugs.

Thanks also to George for his diligence with testing his library and for helping me understand it a little better.

Enjoy,
Mark

Here is the linux build, as promised.

[URL="http://openpfgw.svn.sourceforge.net/viewvc/openpfgw/pfgw_linux_3.2.1_20090809.zip?view=log"]PFGW for Linux[/URL]

Just today I've noticed somewhat of an oddity that appeared before in PFGW 3.2.0, but now is appearing in 3.2.1 in places where it didn't appear before. When a test is in progress, I'm not seeing the "mro=x sum=y/z" part on the status line. I'm not sure exactly what this refers to, but I'd assumed it has to do with roundoff checking. Thus, I was a little surprised when I didn't see it now, and was wondering if this means that PFGW isn't doing roundoff checking for numbers that it doesn't display it on.

Here's two specific examples of this:
[code]PRP: 452*93^51672-1 227500/337900[/code]
This is from a run on a file containing 452*93^n-1 for n=50K-100K that was started earlier today on PFGW 3.2.0, but was switched to 3.2.1 not long ago. While on 3.2.0 it displayed the additional output, but it suddenly stopped (in the middle of a test, if memory serves) when I switched to 3.2.1.
[code]PRP: 166*43^36252+1 7500/196720[/code]
In this case, it's testing a file containing two k's (166 and 648) for Sierpinski base 43, n=25K-100K. Like the above example, this was started earlier today on v3.2.0, and switched to 3.2.1 a few minutes ago, but this time it didn't display the "mro=" stuff with either version.

P.S.: Yowch! I just discovered another really odd occurrence since switching to PFGW 3.2.1. On 3.2.0, I got these timings on the two ranges mentioned above:
[code]452*93^51464-1 is composite: RES64: [7AB30B57B2E2DBB3] (240.6095s+0.0107s)
452*93^51498-1 is composite: RES64: [C26986F583B81467] (256.2330s+0.0111s)
452*93^51608-1 is composite: RES64: [7985AC0305B44E65] (247.3637s+0.0106s)
---------------------
648*43^36047+1 is composite: RES64: [D7CDA03750C324F9] (68.9006s+0.0050s)
166*43^36048+1 is composite: RES64: [147EC266EEEA3410] (68.0290s+0.0051s)
648*43^36067+1 is composite: RES64: [2F47965A2883BD43] (70.9499s+0.0050s)[/code]
However, when I switched to 3.2.1, the timings changed drastically for base 43 but not for base 93:
[code]
452*93^51666-1 is composite: RES64: [E410C86F842311A6] (244.1942s+0.0104s)
452*93^51672-1 is composite: RES64: [51B76772CED926B9] (247.2918s+0.0106s)
452*93^51711-1 is composite: RES64: [F8F10DE402182490] (249.0358s+0.0105s)
-----------------------
166*43^36084+1 is composite: RES64: [E67C4A5407871B82] (250.9955s+0.0066s)
648*43^36163+1 is composite: RES64: [9258F8073A0532F0] (244.2465s+0.0052s)
648*43^36183+1 is composite: RES64: [2775A27E5644CCCB] (246.0343s+0.0053s)[/code]
I've verified that each PFGW instance is getting an entire core to itself, as before. However, I can't seem to find any obvious clue to why this is happening; the two instances are in completely separate folders, so that can't be the problem. Possibly v3.2.1 is picking the wrong FFT size for base 43 or something? I tried restarting the program, but the problem persists, so thus I'd suspect something with the software.

BTW, is it possible to make PFGW output the FFT size it's using to screen for each test?

Edit: Oh, and while I'm at it, I was able to download this one just fine with IE 8. Possibly the problem is specific only to something with the 3.2.0 download.

Edit2: I've switched both clients back to 3.2.0 for now (which seems to work stably for this type of work at least), and the times went back to normal for base 43, but interestingly enough, for base 93, when I first restarted again with 3.2.0 it resumed showing the "mro=" stuff, but now it's stopped (after 3 tests into the resumed load). Anyway, it may not make much of a difference, but I figured I'd mention it for the sake of completeness. :smile:

Sorry. That's my bad. I forgot a + sign in the piece of code that detects whether or not fast modular reduction can be used. This only affects the +1 forms, not the -1 forms. I'll patch it later tonight.

Update regarding the "mro=" thing: now it's reappeared on base 42 (running 3.2.0). It seems almost like it keeps flipping on and off, though it would indeed seem rather odd that it would pick today of all days to start flipping around (since before, when I was testing other bases and k's, it just stayed on constantly except when using PRPnet which runs it in terse mode).

Edit: Hmm, it just flipped off again. Weird.

[QUOTE=mdettweiler;184767]Update regarding the "mro=" thing: now it's reappeared on base 42 (running 3.2.0). It seems almost like it keeps flipping on and off, though it would indeed seem rather odd that it would pick today of all days to start flipping around (since before, when I was testing other bases and k's, it just stayed on constantly except when using PRPnet which runs it in terse mode).

Edit: Hmm, it just flipped off again. Weird.[/QUOTE]

I've decided to give the release a little more time before patching it. There are no other issues at this time.

As for the mro=, it sometimes will show and sometimes not. There are a number of conditions that control whether or not it is displayed. It is informational only.