mersenneforum.org Range for k>300 that Peter Benson has searched
 Register FAQ Search Today's Posts Mark Forums Read

2009-01-13, 22:13   #23
gd_barnes

May 2007
Kansas; USA

5×2,017 Posts

Quote:
 Originally Posted by Flatlander While I'm happy to yield to the majority, here is my reasoning: We are in fact running a project that gives its best shot at "no prime left behind" but will never be able to 'prove' that unless we have for every k/n pair either: a) a factor that has been double checked with a second program. b) matching residuals from two seperate programs. (By 'prove' I mean 'prove beyond all reasonable doubt', whatever that means.) I don't understand why a list of primes generated by P.B. is no longer sufficient to us to count as a first test (even without residues) when it is sufficient for many k<1000.

I had actually "abstained" from the voting because I didn't want to overly influence it. But had I been forced to vote (lol), I would have voted (by a razor-thin margin in my mind) to exclude the k=1005-1400 range assuming that Peter could NOT provide the residuals. If he CAN provide residuals, then I feel strongly that it should be excluded...but by his statement, it's not clear how much he could provide. I'll follow up with him shortly.

True, we cannot say for sure that we are not leaving a prime behind without having exactly what you stated here but we can come as close as possible without spending an undue amount of time.

My reasoning for feeling like we should exclude k=1005-1400 is slightly different than yours:
1. We are a project that is in competition with other projects.
2. We will be running double-checking on all ranges in the future.
3. To include such a large range that we strongly suspect has been fully searched in a 1st pass test and to then double-check it in the future effectively makes it into a triple-check. In my mind, that's OK for a few k's here and there but to do so for such a large range takes too much CPU time away.

If Peter can provide the residuals, then k=1005-1400 becomes no different than Max's k=1003 except that it was done by someone outside of NPLB. The vote was taken assuming that Peter could not provide any residuals. I suspect people will vote differently if we can get the results or a large percentage of them.

If someone outside of NPLB can come in here and provide us with residuals, then we should exclude the k's in a first-pass test IF...it would not be too messy to exclude them. An example of "messy" might be if there were many holes in the residuals where many k's here-and-there or misc. n-ranges were left out. We have found that those are the most error-prone and are always inclined to include them in our first-pass efforts.

As for your saying that a first-pass test without residuals was sufficient for k<1000, that was not true. We allowed it only for k<300 and only because RPS had already done some double-checking in the range. We tested every k for k=300-1001 and n=260K-600K. Even Curtis's mini-drive that was excluded from our team drives was completely checked by me with one missing prime found.

Gary

Last fiddled with by gd_barnes on 2009-01-13 at 22:16

2009-01-13, 22:20   #24
mdettweiler
A Sunny Moo

Aug 2007
USA (GMT-5)

3×2,083 Posts

Quote:
 Originally Posted by gd_barnes I had actually "abstained" from the voting because I didn't want to overly influence it. But had I been forced to vote (lol), I would have voted (by a razor-thin margin in my mind) to exclude the k=1005-1400 range assuming that Peter could NOT provide the residuals. If he CAN provide residuals, then I feel strongly that it should be excluded...but by his statement, it's not clear how much he could provide. I'll follow up with him shortly. True, we cannot say for sure that we are not leaving a prime behind without having exactly what you stated here but we can come as close as possible without spending an undue amount of time. My reasoning for feeling like we should exclude k=1005-1400 is slightly different than yours: 1. We are a project that is in competition with other projects. 2. We will be running double-checking on all ranges in the future. 3. To include such a large range that we strongly suspect has been fully searched in a 1st pass test and to then double-check it in the future effectively makes it into a triple-check. In my mind, that's OK for a few k's here and there but to do so for such a large range takes too much CPU time away. If Peter can provide the residuals, then k=1005-1400 becomes no different than Max's k=1003 except that it was done by someone outside of NPLB. The vote was taken assuming that Peter could not provide any residuals. I suspect people will vote differently if we can get the results or a large percentage of them. If someone outside of NPLB can come in here and provide us with residuals, then we should exclude the k's in a first-pass test IF...it would not be too messy to exclude them. An example of "messy" might be if there were many holes in the residuals where many k's here-and-there or misc. n-ranges were left out. We have found that those are the most error-prone and are always inclined to include them in our first-pass efforts. As for your saying that a first-pass test without residuals was sufficient for k<1000, that was not true. We allowed it only for k<300 and only because RPS had already done some double-checking in the range. We tested every k for k=300-1001 and n=260K-600K. Even Curtis's mini-drive that was excluded from our team drives was completely checked by me with one missing prime found. Gary
Hmm...well, now that you put it that way, I think I'm in favor of omitting the range for now, too, especially since, as you said, we'll eventually be doublechecking all these ranges anyway.

Max

2009-01-13, 22:26   #25
gd_barnes

May 2007
Kansas; USA

5×2,017 Posts

Quote:
 Originally Posted by pb386 I probably have a lot of results from k=1003-1399. If I gather these all together from their separate files, will they be useful to you? There will be gaps in what I can salvage but can you (& do you want to) exclude candidates I have residues for?

Thanks for the excellent offer Peter!

Yes, please send me all the results that you have for k=1003-1400. We're looking to start the drive on the 17th. If you don't feel you have the time to pull everything off before then, please send some of what you have and a general synopsis of what is remaining to send before that date that would help us make a clearer decision. My Email address is:

gbarnes017 at gmail dot com

I think we'll be curious as to how the great Peter Benson has chosen to divide up these huge ranges on his machines.

Everyone, the vote was taken assuming no residuals from Peter. I'll take a look at what we get from him and post a synopsis here, which will include any holes in the ranges. People can then state if they wish to change their vote.

Thanks again Peter.

Gary

2009-01-13, 22:29   #26
gd_barnes

May 2007
Kansas; USA

235458 Posts

Quote:
 Originally Posted by mdettweiler Hmm...well, now that you put it that way, I think I'm in favor of omitting the range for now, too, especially since, as you said, we'll eventually be doublechecking all these ranges anyway. Max

There I go influencing people's vote again.

Keep in mind that I don't care how you vote. It should be all your own after getting all the appropriate info. on both sides of the issue...kind of like voting for anyone/anything in the political arena.

Last fiddled with by gd_barnes on 2009-01-13 at 22:32

2009-01-13, 22:31   #27
Flatlander
I quite division it

"Chris"
Feb 2005
England

31×67 Posts

Quote:
 Originally Posted by gd_barnes ... As for your saying that a first-pass test without residuals was sufficient for k<1000, that was not true. We allowed it only for k<300 and only because RPS had already done some double-checking in the range. We tested every k for k=300-1001 and n=260K-600K. Even Curtis's mini-drive that was excluded from our team drives was completely checked by me with one missing prime found. Gary
I was thinking specifically about the double-checking drive, where we have no residues for the first pass but still call it 'double-checking'. (Though, admittedly, I did think there were other ranges without residues.)

2009-01-13, 22:40   #28
IronBits
I ♥ BOINC!

Oct 2002
Glendale, AZ. (USA)

100010110012 Posts

This statement is opposite of what No Prime Left Behind! means.

Quote:
 True, we cannot say for sure that we are not leaving a prime behind without having exactly what you stated here but we can come as close as possible without spending an undue amount of time.
Set it up to be run by a llrnet server so I can run it and if someone wants to help me with it, they can.

No Prime Left Behind! :)

2009-01-14, 00:39   #29
gd_barnes

May 2007
Kansas; USA

1008510 Posts

Quote:
 Originally Posted by IronBits This statement is opposite of what No Prime Left Behind! means. Set it up to be run by a llrnet server so I can run it and if someone wants to help me with it, they can. No Prime Left Behind! :)

My statement referred to ALL ranges at NPLB. Not just the k=1005-1400 range. In other words, barring a great expenditure of human time and computer resources, we cannot know for sure that we are not leaving primes behind in ANY range that we search. Actually, it would be the human time involved to compile such an extensive database of factors and residuals that would be the issue more than anything.

Before making a final decision on this, let's see what residuals that Peter can provide.

Excluding any vote by me (which would be more like 0.6-0.4 in favor of EXcluding the range), it's still 3-2 in favor of INcluding the entire range after the change by Max. I'll only vote if there is a tie since I'm so close on the issue. But I think we need to see what Peter has first.

Gary

Last fiddled with by gd_barnes on 2009-01-14 at 00:41

 2009-01-14, 07:28 #30 henryzz Just call me Henry     "David" Sep 2007 Cambridge (GMT) 564610 Posts personally i would say include all that benson cant provide results for
 2009-01-14, 07:55 #31 MooooMoo Apprentice Crank     Mar 2006 7068 Posts I'll vote for excluding k=1000 - 1400 if the residues are provided. Also, exclude k=1991. I have residues for that k too
 2009-01-17, 00:56 #32 gd_barnes     May 2007 Kansas; USA 5·2,017 Posts Well...good news everyone. Early this morning, I got a multitude of results from Peter Benson for k=1005-1400 and n>350K. In looking at a couple of files, it does appear that he has searched every k from k=1005-1400. He states that there is some 'holes' in the results so I'll be analyzing them in more detail later tonight but a preliminary look shows that we have most of what we need. The ranges that he sent so far are k=1005-1400 for n=300K-335.1K and 350K-479264. He stated that he is working on n>479264 at the moment. He has also offered to send n=170K-300K for the smaller k-range of k=1005-1100. Based on the above, I've sent him back several questions that will impact what we hand out next on the 9th drive (non-top 5000 work): 1. Did he test and have results available for k=1100-1400 for n=170K-300K? I'm only asking for the n=200K-300K results since we're already doing n=170K-200K in that drive. 2. Did he test and have results available for k=1005-1400 for n=335.1K-350K? 3. Will he be testing k=1005-1400 up to n=600K? If so, I've asked if he could forward the results on those when he is done. If we can get the results in #1 & 2, we'll pull k=1005-1400 for n=200K-350K out of our 9th drive. Regardless of that, he has sent us everything he has on the higher-priority range for our 8th drive. Assuming that the holes are minimal, I definitely agree with Henry and Mike that we should exclude anything that we have results for. If the holes are small, we can "fill them in" if we feel it is necessary after the drive is done. With my vote to exclude the range with results in hand, this would put it at 5-3 in favor of excluding the range with the results in hand, although I suspect that 1 or more of the 3 who voted to include it may change their vote now. Anyway, everyone feel free to express your opinions still. We'll use his residues for comparison on a future double-check drive. By doing this, we'll be avoiding what amounts to a triple-check on a huge k-range. Karsten, I know this will sound a little messy for your pages. Here is what I will do assuming that we exclude the range after the sieving drive is done: 1. Send you a sieve file that has only k=1005-1400 in it for n=350K-500K sorted by n-value. This will not be used for our current drive but will be used for future double-checking. 2. Send you a sieve file that has only k=1400-2000 in it for n=350K-500K sorted by n-value. That is what we will include in the 8th drive. 3. I'll hold off sending you a sieve file for k=1005-2000 for n=200K-350K for our 9th drive until we find out for sure what Peter has processed and can send us results for. As soon as we find out, I'll send you appropriately divided up files sorted by k-value. Like n=50K-200K, we'll process n=200K-350K by k also to keep it easy on your entry in the pages. Gary Last fiddled with by gd_barnes on 2009-01-17 at 09:00
 2009-01-17, 09:20 #33 gd_barnes     May 2007 Kansas; USA 5×2,017 Posts OK, folks after much effort, I have analyzed Peter's results files for k=1005-1400 and n=350K-479264 as much as I think is necessary. Here is what I found: 1. We have approximately 95.3% of the results. 2. All of the holes are spread out throughtout the range; most are n=~50. The largest is n=260 at a low n-range. 3. All primes in the results files have been reported on the top-5000 site. 4. The results files contain 95.6% of the primes that have been reported on the top-5000 site for the k and n-range. 5. The files sent were very organized and all k's were clearly searched for all n-ranges. The timings also appeared quite stable across large n-ranges. (Excellent for such huge ranges!) 6. For n>420K, there were only 2.5% missing results. Because the % of primes missing in the results is almost identical to the % of actual missing results, the missing results was declining, and clearly all k's were searched, I'm confident that the entire range has been searched. In other words, the missing results likely came about for the same reason that I have a few missing results for NPLB and some of my own efforts...that is they end up getting inadvertantely deleted, misfiled, a hard-drive crash happens, or some other nefarious happening despite one's best intentions. Conclusion: Exclude k=1005-1400 from the 8th drive and run an ongoing side effort (not a drive) to fill in the holes later on. Likely, we could just put them on a low-priority server of mine and when anyone has a spare core for a few days, then they can run it. This is not something that we'd have any official thread for or need any extra web page created for. I'll likely just announce in the news and mention whatever temp. server is running it. I have compiled a spreadsheet of the exact missing n-ranges that I will send to Max and Karsten so it will be easy enough to extract the needed k/n pairs from the big sieve file if I'm not available. Peter has already stated that he will be taking the range up to n=600K so I'm asking him to send results for it as it is convienient for him. Therefore when we take this k-range above n=500K, we'll also exclude n=500K-600K from our effort assuming that we have good results files from Peter. Karsten, my sieving for the P=8.2T-8.6T range will finish in ~5-6 hours. After that, I'll send you and Max the appropriate sieve files for the 8th drive. Late Saturday, the 8th drive resumes! Gary Last fiddled with by gd_barnes on 2009-01-17 at 09:30

 Similar Threads Thread Thread Starter Forum Replies Last Post mickfrancis Computer Science & Computational Number Theory 3 2015-06-25 14:32 R.D. Silverman Factoring 8 2014-06-07 18:43 3.14159 Miscellaneous Math 2 2010-12-04 13:09 Kosmaj Riesel Prime Search 67 2009-01-18 21:59 gd_barnes No Prime Left Behind 20 2008-12-26 08:13

All times are UTC. The time now is 22:22.

Sun Mar 29 22:22:57 UTC 2020 up 4 days, 19:56, 3 users, load averages: 1.74, 1.56, 1.41

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.