20090928, 18:02  #67 
"Phil"
Sep 2002
Tracktown, U.S.A.
3×373 Posts 
I confirmed Ben's residue, so his computer seemed to completely recover from the SUMOUT error, very reassuring. I also retested the two roundoff errors from another user, and confirmed the residue with one error, but got something different for the other which had two roundoff errors. He says that the machine has tested as quite stable several times, but on the theory that perhaps airflow could have been inhibited temporarily, I will retest a few more residues from around the same time as the first, just to get a clearer picture.

20091002, 00:53  #68 
"Serge"
Mar 2008
Phi(4,2^7658614+1)/2
41·229 Posts 
It's ok. We know where they live...

20091010, 00:25  #69 
"Phil"
Sep 2002
Tracktown, U.S.A.
3·373 Posts 
This project was launched one year ago, and has accomplished so much: Three prp discoveries, and we are closing in on testing all exponents below 5M on the two remaining sequences, plus completing sieving up to 500T. Ben and I have been doing a systematic doublecheck on all exponents below 1.25M because of the bugs in pfgw, but we are also launching a random doublecheck of the range from 1.25M to 5.01M. I have randomly picked one test to do in each range, with the constraint that it has not already been doublechecked. This account for 376 tests. I also added another 16 tests that occurred at times that there were hardware errors occurring. Although these 16 tests were all reported with clean error codes, because they occurred at the same time as other errors were generated, or during times of high heat on the cores, this may give us a chance to see if there were other undetected problems. The 376 + 16 = 392 tests were divided into 4 work files of 98 tests each and sent to Engracio, Ben, Jeff, and myself. These work files should be a little shorter than the current ones because some of the tests are on numbers with small exponents. I am hoping that by December, we can get an estimate of our error rate and decide whether further error testing is needed. This doublecheck of the 392 tests represents about 1% of our total prp effort to date, and should give us a good idea of how likely it might be that we could have missed a prime.
Thanks everyone for your contributions to a very successful project so far! 
20091205, 00:10  #70 
"Phil"
Sep 2002
Tracktown, U.S.A.
3·373 Posts 
Double checking
The double checking data is in, so I would like to provide a summary of what we know about the accuracy of our data so far. Before getting in to the data, I want to first mention that 11 firsttime checks (out of 38,000 or so) have been returned so far with bits set in the errorreporting word. Some errors (SUMOUT) tend to be less disruptive than others (ROUNDOFF, or SUMINP!=SUMOUT), and the program can often recover by restarting from the last save file. Of these 11 residues reported with errors, we have confirmed that 8 of them were correct residues and 3 were incorrect, with a triplecheck needed to confirm the incorrect residues. There were also two file reading errors caused by simultaneous testing of two numbers with the same exponent but different k values. I believe this is because Prime95 uses the same naming convention for both save files, but a double check has confirmed that both residues were correct.
All other residues were reported without detected errors. I randomly chose one prp test in each 10k range to retest. The k values were all either 40291 or 41693. (If I had known we would find another prp so soon, I would have postponed this project!) From 1.25M to 5.01M, this gave a total of 376 prp tests to redo. To these, I added an additional 16 tests which were in the vicinity of reported errors on the theory that there may have been unreported errors (particularly ROUNDOFF errors) near the same time and from the same machines as the reported errors, for a total of 392 prp tests. From the first 294 tests, there was only one discrepancy between the first time test and the doublecheck. The discrepancy has been confirmed via a triple check as an error in the first time test. The machine was the same quad of Jeff's that had returned one of the three bad residues with a reported error. Considering that this machine had only returned about 350 tests in all, very few of those residues were doublechecked, and I was concerned that it might have a high error rate. Engracio volunteered to double check another 32 residues from that machine, and he confirmed that 31 of the residues were ok, and one was wrong (confirmed by my triplecheck.) So we have about a 6% error rate (2 out of 33, not including the ROUNDOFF error result), although I would not be surprised if the true error rate on this machine is anywhere between 2% and 12%. My suggestion is, let's doublecheck the 105 remaining residues from this machine in the 40291 sequence, and just forget about 41693 and 2131. The chances are small that one of them is a prp, but I would feel rather silly if they finally got checked a couple of years from now and a prp turned up! Anyone want to volunteer? All 105 tests are between 3.05M and 3.92M. So I was hoping for a low error rate, but I got paleseptember's double check file last night and found two more discrepancies with the first time checks which were done by engracio. I am triple checking the first one (on a very slow machine) to find out which results were in error. (Anyone with a faster machine want to test 2^4007127+41693 for me? Otherwise, I will be done late next week.) Still an overall error rate of < 1% (3 out of 394 or less). But we can expect the error rate to grow as the exponents get larger. Maybe we should periodically do more of this sort of sample double checking, and perhaps we will even be lucky enough to identify machines that have higher than usual error rates. Ben and I have done a lot of work double checking exponents < 1.25M, but we have not found even a single error yet, so I'm not sure that more systematic checking of the low exponents has a very good payoff. So I think the error rate is low enough that we can concentrate on firsttime tests for awhile. What about sieving? We are currently sieving from 2M to 50M, so any factors found < 5.2M are only benefitting future doublechecking work. Should we drop 2M5M from our sieving range? For the record, sieving speed is proportional to the squareroot of the range size, so dropping 25M would only speed up our sieving by a bit over 3%. Maybe we should sieve a bit farther before raising the lower limit on sieving. Opinions? 
20091205, 00:21  #71 
May 2007
11^{2} Posts 
Hey Phil I will take those 105 dc. I am finishing up my last range and I will complete this set of dc before reserving again.

20091205, 01:38  #72 
"Phil"
Sep 2002
Tracktown, U.S.A.
3·373 Posts 
Thanks, Engracio, I emailed them to you.

20091205, 05:21  #73 
May 2007
11^{2} Posts 
They are on the queue to be worked on.

20091205, 23:51  #74 
"Phil"
Sep 2002
Tracktown, U.S.A.
3·373 Posts 
Ignore my request on 2^4007127+41693, as it is now started and will finish early Tuesday. I have confirmed the first residue mismatch from Ben as being wrong on Engracio's end, so I'll be in touch with him to see if we can identify the computer that ran that test.

20091206, 00:47  #75 
May 2007
11^{2} Posts 
Phil if that was the same 3 or 4 wu we discussed before, I believe I do not have that machine anymore due to the mobo dying. So I do not think we can reproduce the results other than redoing the the test..

20091206, 22:31  #76 
Sep 2009
11 Posts 
Double checking
Phil,
Given that the mean nb of primes per doubling is now 0.19, the probability of finding a yet undiscovered PRP by doublechecking the last sequence (40291) in the relevant range (1.25M to 5.2M) is quite low, around 6%*(1exp(0.19*LN(5.2/1.25)/LN(2))) = 2%. Thus for this last sequence double checking would better be considered in the future by managing the expected increasing error rate along with increasing exponent. OTOH for the other sequences I would suggest to make a double checking up to the discovered PRP exponent in order to ensure that it is indeed the lowest exponent ("Keller prime"). I think it would not be an unbearable task, it could result in easing the search for prime proof, and if clearly mentioned, would spare dispersed efforts of finding such hypothetical lower PRPs. Don't forget that for k=67607 the exponent 46549 had been discovered before 16389. 
20091206, 23:35  #77 
"Phil"
Sep 2002
Tracktown, U.S.A.
3·373 Posts 
6% was only the estimated error rate for that one computer that has returned three bad results so far; our overall error rate is probably more like 1% or less. As you say, the odds are small that a prime was missed for 40291.
On the other hand, doublechecking all the sequences in which a prp has been discovered would be an effort comparable to a good fraction of our total effort to date, especially for 2131 and 41693. My current goal is to finish a complete list of residues for each of the four sequences so that they can eventually be doublechecked, but I don't think we are ready to divert large amounts of resources to that task just yet. 
Thread Tools  
Similar Threads  
Thread  Thread Starter  Forum  Replies  Last Post 
P1 discussion thread  Rincewind  Five or Bust  The Dual Sierpinski Problem  57  20110206 21:53 
Sieving discussion thread  jasong  Twin Prime Search  311  20101022 18:41 
Sieving discussion thread  philmoore  Five or Bust  The Dual Sierpinski Problem  66  20100210 14:34 
Theological Discussion Thread  clowns789  Soap Box  3  20060309 04:05 
New Sieve Thread Discussion  Citrix  Prime Sierpinski Project  15  20050829 13:56 