mersenneforum.org PFGW 3.2.1 has been released
 Register FAQ Search Today's Posts Mark Forums Read

 2009-08-09, 15:57 #1 rogue     "Mark" Apr 2003 Between here and the 696610 Posts 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. PFGW for Windows PFGW for MacIntel 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 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. 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
 2009-08-09, 18:54 #2 rogue     "Mark" Apr 2003 Between here and the 2×34×43 Posts Here is the linux build, as promised. PFGW for Linux
 2009-08-09, 21:34 #3 mdettweiler A Sunny Moo     Aug 2007 USA (GMT-5) 141518 Posts 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 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 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) 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) 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. Last fiddled with by mdettweiler on 2009-08-09 at 21:56
 2009-08-09, 22:33 #4 rogue     "Mark" Apr 2003 Between here and the 2·34·43 Posts 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. Last fiddled with by rogue on 2009-08-09 at 22:41
 2009-08-09, 23:22 #5 mdettweiler A Sunny Moo     Aug 2007 USA (GMT-5) 3·2,083 Posts 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. Last fiddled with by mdettweiler on 2009-08-09 at 23:23
2009-08-10, 01:43   #6
rogue

"Mark"
Apr 2003
Between here and the

2·34·43 Posts

Quote:
 Originally Posted by mdettweiler 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.
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.

 Similar Threads Thread Thread Starter Forum Replies Last Post rogue Software 545 2023-01-20 14:12 rogue Software 94 2010-09-14 21:39 rogue Software 10 2009-10-28 07:07 rogue Software 20 2009-08-23 12:14 rogue Software 25 2009-07-21 18:13

All times are UTC. The time now is 03:27.

Sun Feb 5 03:27:30 UTC 2023 up 171 days, 56 mins, 1 user, load averages: 0.90, 0.85, 0.79