20220909, 11:50  #12  
"Florian"
Oct 2021
Germany
11·17 Posts 
Quote:
I could also remove the automatic algebraic factoring from the code of srsieve2 to see if it produces incorrect results. It seems like a trivial thing to do. 

20220909, 11:52  #13  
"Gary"
May 2007
Overland Park, KS
2·19·317 Posts 
Quote:


20220909, 14:32  #14 
"Curtis"
Feb 2005
Riverside, CA
5729_{10} Posts 
I don't think you need to go as far as retesting all the candidates for primality. Once the new sieves are reasonably deep, compare to the file that was tested for primality, and then run primality tests on all the candidates still in the new sieve that weren't already tested.
You have good reason to trust the primality testing side of the project, so doublechecking the entire range should be put off until after the sieve stuff is investigated. I suppose you might also doublecheck the first 1% of a range and compare residues, just in case there are mismatches. The bug mentioned in the sieve software "should" only affect really small candidates the sieve has no way to know which candidates are prime, unless the sieve depth reaches sqrt of a candidate. So, primes with exponent below 100 could possibly be removed from a sieve rather than reported prime, but not in the ranges you're considering here. Of course, if I'm wrong then we have a new *really* fast way to find primes with just a sieve!!! 
20220909, 21:04  #15 
"Gary"
May 2007
Overland Park, KS
2·19·317 Posts 
Great points, Curtis! Thanks for the thoughts.
Florian just sent me his files sieved to P=200G and 5e12. Mine just finished to 5e12. In a little while, I'll remove the factors and compare them. Perhaps we can just rerun the lower 20% of the range for R88 n=250K300K plus all candidates that are in our file sieved to 5e12 that are not in the file sieved to 5e14. That would be a lot less timeconsuming and give us ~20000 k/n pairs to compare residues. That makes sense about it removing candidates at the lower end of a sieverange that are prime. NewPGen had that issue. I'm glad that was fixed but it should not affect us. Last fiddled with by gd_barnes on 20220910 at 05:04 
20220910, 08:17  #16 
"Gary"
May 2007
Overland Park, KS
12046_{10} Posts 
I have compared the sieves that I did with sr2sieve and the sieves that Florian did with srsieve2. Oddly srsieve2 is missing some factors that were found by sr2sieve but it does not appear to have produced any extra factors that would cause a candidate to be removed incorrectly. All of these missed factors were for k=1247, which happens to be the smallest k in the file out of 19 k's.
There were 43 more factors in the sieve done with sr2sieve vs. the one using srsieve2 at P=2e11, all for k=1247. There were 58 extra factors at P=5e12. Apparently srsieve2 continued to miss factors. I want to do more detailed analysis but I won't have time until later on Saturday. Here are a few notes: 1. I did some spot check with 45 of the factors produced by sr2sieve that were missed by srsieve2 using the FactorDB. They are correct factors. 2. Due to time constraints, I have not yet done a direct compare of the files for other k's because all the counts matched. It's always possible that there could be differences even though the counts are the same. 3. This is more complex than it appears at first glance. In several instances, sr2sieve found a factor that was missed by srsieve2. But then later on srsieve2 found a larger factor to eliminate the same k/n pair making the difference in factor count less than it should be. So the number of missed factors is actually somewhat larger than shown above. 4. The newest version of srsieve2 is unlikely to be the version that was primarily used in the original sieve of this file that produced no primes. So this may not get us anywhere. But it looks like it may highlight some current issues with srsieve2. I will do a more direct compare of things later on Saturday. Last fiddled with by gd_barnes on 20220910 at 08:19 
20220912, 11:09  #17 
"Gary"
May 2007
Overland Park, KS
2·19·317 Posts 
Florian and I have been coordinating on resieving R88 for n=250K500K. I have finished sieving it to P=25e12 using only srsieve followed by sr2sieve. I am keeping every factor found for P>1e9 for the effort.
Currently there are 108,091 tests in our file at P=25e12. There were 98,687 tests in the Yoyo file at P=500e12, which is what SRBase tested with. A difference of 9404 tests. That difference is a little low but is mostly within the margin of error of predicted factors by sr2sieve, which predicts 9567.31 factors for P=25e12 to 500e12. Originally I was thinking of suggesting that SRBase test the difference in k/n pairs at this point. But we are considering sieving it further while continuing to keep a detailed accounting of the factors found. 
20221016, 12:43  #18 
Sep 2011
Germany
3,469 Posts 
Iam rerunning R88_250300k on SRBase with the new llr2 app for double checking, unfortunately the app is 400s slower on my CPU than llr3.8.21. Should take a month or less if nothing happens again.

20221016, 18:50  #19  
"Gary"
May 2007
Overland Park, KS
2·19·317 Posts 
Quote:
That's a good start. As residues come out, you can do a compare on them. I also have a file sieved by Luminescence and me to P=1e14 (mostly by him) where I've been able to verify that all of the factors removed were good. The original file that SRBase tested with was sieved to 5e14. After you are done with 250k300k, what we can do is test the candidates that are in our new file that are not in the one that was sieved more deeply. We are looking for two verifications here: 1. The residues match. 2. The original sieve file is good. Last fiddled with by gd_barnes on 20221016 at 18:52 

20221104, 16:42  #20  
Sep 2011
Germany
3,469 Posts 
Quote:
The dc is done with llr2, less then 170 results were not matched in residues and no prime was found. 

20221122, 00:41  #21 
"Gary"
May 2007
Overland Park, KS
2×19×317 Posts 
For R88, we are currently doublechecking the n=300k350k range and firsttime testing of candidates that were sieved out between P=100e12 and 500e12 for the entire n=250k500k range.
No missing primes were found in the original n=250k300k range. This should be a sufficient doublecheck for R88. Over the next several months, we will put together a plan to doublecheck a portion of all of the bases in 2022 that had 2 k's remaining and no primes for n=300k500k. 
20221122, 16:35  #22  
Sep 2011
Germany
3,469 Posts 
Quote:
R88 250500k testing range complete, no primes found, 300350k double check range matching all residues with the first run If you have another important base to double check where a prime is expected but doesnt find anything let me know. 

Thread Tools  
Similar Threads  
Thread  Thread Starter  Forum  Replies  Last Post 
RSP Sieve Files for k*2^n1 from PrimeGrid  pinhodecarlos  Riesel Prime Search  103  20221126 15:02 
Largest k*2^n1 Primes Found In 2020  andyhedges  Riesel Prime Search  5  20210102 00:09 
I found a sieve to search all pairs of twin primes  Pietro Maiorana  Twin Prime Search  8  20190926 23:07 
Algebraic factors in sieve files  pepi37  Conjectures 'R Us  95  20170704 13:37 
program to verify factors found by sr(x)sieve?  mdettweiler  Software  16  20090308 02:06 