mersenneforum.org  

Go Back   mersenneforum.org > Prime Search Projects > Five or Bust - The Dual Sierpinski Problem

Reply
 
Thread Tools
Old 2009-09-20, 22:37   #56
paleseptember
 
paleseptember's Avatar
 
Jun 2008
Wollongong, .au

2678 Posts
Default

Alrighty, I have a full double-check of 1.00-1.10M is running now. Should be done in less than a week.
paleseptember is offline   Reply With Quote
Old 2009-09-24, 23:26   #57
paleseptember
 
paleseptember's Avatar
 
Jun 2008
Wollongong, .au

3×61 Posts
Default

Double-check on 1.00-1.10M is complete, results and residues have been forwarded to Phil. Hopefully he has a nice little script that strips out the important data from the first-run and double-check files and compares the res64 and Wd1 details.

Double-check on 1.10-1.25M is now running. Estimated time to completion approximately 6 days, making it 1st October barring any significant issues.

~ps~
paleseptember is offline   Reply With Quote
Old 2009-09-25, 22:44   #58
philmoore
 
philmoore's Avatar
 
"Phil"
Sep 2002
Tracktown, U.S.A.

22·32·31 Posts
Default

I have completed a double check of the range 0-500,000 also, and I am pleased to report that we now have complete residue matches of each double check in this range, as well as Ben's range 1M-1.1M, with earlier residues from pfgw, either 64-bit residues from version 20050213 or 62-bit residues from version 20041129. I am continuing with 500,000-1M, and Ben is continuing from 1.1M-1.24M, but the only range where 20050213 had the hiccups was between 500,000 and 600,000, and I should have that done fairly soon. If it checks out, I do not anticipate any further problems, but I still intend to complete the double checking up to 1M, because the only residues we have currently in this range are from the 20050213 version of pfgw which had known bugs. After 1.24M, all residues are from version 25 of Prime95 (or mprime) which I presume was probably working correctly.

I also did a scan of all our results files returned so far, and found three tests that were returned with non-zero error codes, two with ROUND-OFF errors and one with a SUMOUTerror. Not bad, out of 38,000 or so tests completed so far! I have contacted the people who sent me the errors by email so that they can investigate whether they have any stability issues with those particular machines.

I will pick some random double checks to rerun and send a file out to each volunteer before too long, and hopefully we can get some sort of estimate of our current error rate.
philmoore is offline   Reply With Quote
Old 2009-09-25, 23:46   #59
mdettweiler
A Sunny Moo
 
mdettweiler's Avatar
 
Aug 2007
USA (GMT-5)

186116 Posts
Default

Quote:
Originally Posted by philmoore View Post
I also did a scan of all our results files returned so far, and found three tests that were returned with non-zero error codes, two with ROUND-OFF errors and one with a SUMOUTerror. Not bad, out of 38,000 or so tests completed so far! I have contacted the people who sent me the errors by email so that they can investigate whether they have any stability issues with those particular machines.
There is a known issue in PFGW that causes repeatable roundoff errors on certain candidates near FFT boundaries, not necessarily due to an unstable machine. Try rerunning those candidates with the -a1 switch and you should be able to finish the test and get a (hopefully) matching residual set.

As for the sumout errors, I'm not sure if those are due to a bug or what.

BTW, why did you use the 20050213 and 20041129 versions of PFGW for the earlier results? Everything up through version 3.1.0 (I don't know the exact release date for 3.1.0, but it was somewhere in 2009) produced 62-bit residues even though they were outputted as "64-bit" residuals (essentially the first character was repeatable but nonetheless inaccurate and could be thrown out for comparison with other 62-bit residues). The 20050213 version which you used for 64-bit residuals was actually outputting 62-bit ones in this manner.

In fact, you could just as well use the latest, true 64-bit residue version of PFGW (3.2.2) for comparison with originally 62-bit residuals, as long as you ignore the first character of the 64-bit ones when comparing them. You could even use Prime95 for this if you wanted since it produces the same true 64-bit residues as the latest version of PFGW.
mdettweiler is offline   Reply With Quote
Old 2009-09-26, 00:10   #60
paleseptember
 
paleseptember's Avatar
 
Jun 2008
Wollongong, .au

3·61 Posts
Default

The SUMOUT error was from me, and I'm pretty sure it was a result of a power black-out. Phil is rerunning the test, hopefully it'll check out.
paleseptember is offline   Reply With Quote
Old 2009-09-26, 03:37   #61
philmoore
 
philmoore's Avatar
 
"Phil"
Sep 2002
Tracktown, U.S.A.

22×32×31 Posts
Default

Quote:
Originally Posted by mdettweiler View Post
There is a known issue in PFGW that causes repeatable roundoff errors on certain candidates near FFT boundaries, not necessarily due to an unstable machine. Try rerunning those candidates with the -a1 switch and you should be able to finish the test and get a (hopefully) matching residual set.
If this is true, it will also be true with the latest version of Prime95, as both programs use the same FFT boundaries. However, the errors I referred to were occurring with version 20050213. On that version, the -a1 switch was broken.

Quote:
Originally Posted by mdettweiler View Post
BTW, why did you use the 20050213 and 20041129 versions of PFGW for the earlier results? Everything up through version 3.1.0 (I don't know the exact release date for 3.1.0, but it was somewhere in 2009) produced 62-bit residues even though they were outputted as "64-bit" residuals (essentially the first character was repeatable but nonetheless inaccurate and could be thrown out for comparison with other 62-bit residues). The 20050213 version which you used for 64-bit residuals was actually outputting 62-bit ones in this manner.
All of the earlier results were run prior to August 2008, and the 3.x.x versions of pfgw were not available then. The 20050213 actually output full 64-bit residuals, not 62-bit as was the case with 20041129.

Quote:
Originally Posted by mdettweiler View Post
In fact, you could just as well use the latest, true 64-bit residue version of PFGW (3.2.2) for comparison with originally 62-bit residuals, as long as you ignore the first character of the 64-bit ones when comparing them. You could even use Prime95 for this if you wanted since it produces the same true 64-bit residues as the latest version of PFGW.
We are using Prime95 (or mprime) for this. See my response to your earlier post in post #45.
philmoore is offline   Reply With Quote
Old 2009-09-26, 10:44   #62
mdettweiler
A Sunny Moo
 
mdettweiler's Avatar
 
Aug 2007
USA (GMT-5)

792 Posts
Default

Quote:
Originally Posted by philmoore View Post
If this is true, it will also be true with the latest version of Prime95, as both programs use the same FFT boundaries. However, the errors I referred to were occurring with version 20050213. On that version, the -a1 switch was broken.
Yes, correct, it is broken in Prime95 as well. In that case, I guess it's probably a different problem (whether repeatable due to program bug or due to an unstable machine).
Quote:
All of the earlier results were run prior to August 2008, and the 3.x.x versions of pfgw were not available then. The 20050213 actually output full 64-bit residuals, not 62-bit as was the case with 20041129.
Are you sure about that? Because when I asked Mark (rogue), the current developer of PFGW about that, he said that even when pre-3.2.0 versions seemingly outputted 64-bit residuals, they were really 62-bit ones, and thus the first bit was incorrect (though reproducible). I.e., if you ran the same test with Prime95, you'd get a residual that's the same except for the first character.

I think the 20041129 version may have not even tried to print 64-bit residuals, but rather only printed the 62-bit residual (i.e. leaving off the first character entirely). Don't quote me on that though.
Quote:
We are using Prime95 (or mprime) for this. See my response to your earlier post in post #45.
Oh, I see. I think I was a little confused by this remark you made in post #42:
Quote:
Originally Posted by philmoore View Post
The problems were particularly severe for the 2131 sequence, and many residues had to be retested with the older 20041129 version of pfgw, slower by a factor of 2, but apparently accurate and stable.
I'm assuming I read that wrong, then?
mdettweiler is offline   Reply With Quote
Old 2009-09-26, 16:49   #63
philmoore
 
philmoore's Avatar
 
"Phil"
Sep 2002
Tracktown, U.S.A.

100010111002 Posts
Default

Quote:
Originally Posted by mdettweiler View Post
Are you sure about that? Because when I asked Mark (rogue), the current developer of PFGW about that, he said that even when pre-3.2.0 versions seemingly outputted 64-bit residuals, they were really 62-bit ones, and thus the first bit was incorrect (though reproducible). I.e., if you ran the same test with Prime95, you'd get a residual that's the same except for the first character.
Yes, I am sure. We have already checked thousands of residues, and the 64-bit residues from 20050213 match the 64-bit residues of Prime95, version 25, in most cases. The 62-bit residues always had the first character as 0, 1, 2, or 3, but if you masked the leading two bits of a 64-bit residue, the rest of it matched, at least in all cases checked so far.
philmoore is offline   Reply With Quote
Old 2009-09-26, 17:26   #64
mdettweiler
A Sunny Moo
 
mdettweiler's Avatar
 
Aug 2007
USA (GMT-5)

792 Posts
Default

Quote:
Originally Posted by philmoore View Post
Yes, I am sure. We have already checked thousands of residues, and the 64-bit residues from 20050213 match the 64-bit residues of Prime95, version 25, in most cases. The 62-bit residues always had the first character as 0, 1, 2, or 3, but if you masked the leading two bits of a 64-bit residue, the rest of it matched, at least in all cases checked so far.
Ah, I see. I'm surprised that the 20051213 version actually produced true 64-bit residues; was it a specially "hacked" version by chance? Because if so, that would explain why the 64-bit residue code hadn't stuck around, and was "newly" added in version 3.2.0 not long ago.

Last fiddled with by mdettweiler on 2009-09-26 at 17:26
mdettweiler is offline   Reply With Quote
Old 2009-09-26, 21:22   #65
philmoore
 
philmoore's Avatar
 
"Phil"
Sep 2002
Tracktown, U.S.A.

111610 Posts
Default

I wouldn't say that 20050213 was hacked, but it had a number of enhancements that had been added by Jim Fougeron, the same guy who had put out many of the previous versions. It was officially a "beta" version, while the earlier 20041129 was an "alpha" version, presumably stable but with much slower FFT routines for numbers of the form a*2^n+b. Unfortunately, when Mark decided to update pfgw, he was unable to obtain Jim's source code which contained the newer enhancements.
philmoore is offline   Reply With Quote
Old 2009-09-26, 22:23   #66
mdettweiler
A Sunny Moo
 
mdettweiler's Avatar
 
Aug 2007
USA (GMT-5)

792 Posts
Default

Quote:
Originally Posted by philmoore View Post
I wouldn't say that 20050213 was hacked, but it had a number of enhancements that had been added by Jim Fougeron, the same guy who had put out many of the previous versions. It was officially a "beta" version, while the earlier 20041129 was an "alpha" version, presumably stable but with much slower FFT routines for numbers of the form a*2^n+b. Unfortunately, when Mark decided to update pfgw, he was unable to obtain Jim's source code which contained the newer enhancements.
Ah, I see...that would explain it.
mdettweiler is offline   Reply With Quote
Reply

Thread Tools


Similar Threads
Thread Thread Starter Forum Replies Last Post
P-1 discussion thread Rincewind Five or Bust - The Dual Sierpinski Problem 57 2011-02-06 21:53
Sieving discussion thread jasong Twin Prime Search 311 2010-10-22 18:41
Sieving discussion thread philmoore Five or Bust - The Dual Sierpinski Problem 66 2010-02-10 14:34
Theological Discussion Thread clowns789 Soap Box 3 2006-03-09 04:05
New Sieve Thread Discussion Citrix Prime Sierpinski Project 15 2005-08-29 13:56

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

Sat Nov 28 03:04:37 UTC 2020 up 79 days, 15 mins, 3 users, load averages: 1.35, 1.20, 1.13

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.

This forum has received and complied with 0 (zero) government requests for information.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.
A copy of the license is included in the FAQ.