PRP discussion thread

[paleseptember]

Alrighty, I have a full double-check of 1.00-1.10M is running now. Should be done in less than a week.

[paleseptember]

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~

[philmoore]

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.

[mdettweiler]

Originally Posted by philmoore

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.

[paleseptember]

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.

[philmoore]

Originally Posted by mdettweiler

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.

Originally Posted by mdettweiler

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.

Originally Posted by mdettweiler

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.

[mdettweiler]

Originally Posted by philmoore

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).

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.

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:

Originally Posted by philmoore

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?

[philmoore]

Originally Posted by mdettweiler

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.

[mdettweiler]

Originally Posted by philmoore

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.

[philmoore]

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.

[mdettweiler]

Originally Posted by philmoore

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.