Join PrimeGrid
Returning Participants
Community
Leader Boards
Results
Other
drummerslowrise

Message boards :
Proth Prime Search :
Some k values (multipliers) are green?
Author 
Message 

When I look at "Subproject status", "Proth Prime Search", "Range statistics", some k values (multipliers) like k = 383, 467, 769, 773, 1175, are marked with green color and have no tasks in progress.
What is special about these values? Is it just by coincidence that these k currently have no tasks running? They do have some Tasks Waiting.
(Similar exceptional multipliers are seen in the other Proth subprojects.)
If the only thing about them is that no task is currently in progress, maybe you should just leave them white. Or at least pick a different color from the one you use for k = 5 ... 299 which are inactive (Tasks Waiting is zero).
/JeppeSN  

JimBHonorary cruncher Send message
Joined: 4 Aug 11 Posts: 916 ID: 107307 Credit: 974,532,191 RAC: 0

Yes, it's coincidence in that case. But in the case of PPS, I'm still compensating years later for ranges that were tested unevenly. Here are my notes on what's been tested:
k max n loaded
5 6M digits: 1,806,181
7 6M digits: 1,806,181
9 4M digits: 1,204,121 also n=3.322M3419982 in PRPNet MEGA but that was overlap, everything under 4M tested
1199 3.322M digits: 1,000,022 also n=3.322M3.6M in PRPNet MEGA, completely tested to 3.6M
101299 3.05M digits: 918,144 already done 3.322M3.6M in MEGA search
301399 2.6M digits: 782,685 loaded 3.322M3.6M in MEGA search 20160220
401499 2.6M digits: 782,685 loaded 3.322M3.6M in MEGA search 20160614
5011199 2.6M digits: 782,685 MEGA: generated 3.322M3.6M in 7 files, loaded 3.433M3.466M 20170622
For the next few years I'm loading only k=3011199 on PPS because that has to catch up to where the lower k's have gotten. At n=3.05M I'll include k=101299. When all k's get to n=3.322M then PPS will be doing all megaprime work and the MEGA project will in all likelihood switch to the PPSE k=12019999 range. I can always convert alreadyloaded MEGA candidates to PPS with a query and will work it out when we get there.
Addendum: It's also possible we'll DC the PRPNet MEGA work when PPS reaches n=3.322M. That's years away at this point.  

JimBHonorary cruncher Send message
Joined: 4 Aug 11 Posts: 916 ID: 107307 Credit: 974,532,191 RAC: 0

About the colors: The stats code leaves a lot to be desired. I've been updating it slowly and have many subprojects precalculating the stats on a cron so that the pages load faster. I see what you mean about the colors, but honestly I have bigger things to worry about. I'll keep it in the back of my mind.  


Thank you, Jim, for your answer and for the other interesting info on the search history here. /JeppeSN  

JimBHonorary cruncher Send message
Joined: 4 Aug 11 Posts: 916 ID: 107307 Credit: 974,532,191 RAC: 0

I've now changed both PPS and PPSE stats so that the color keys on the "tasks waiting" number rather than the "in progress" number. The result is that k's where there are currently no workunits in progress but have work waiting show up in white like other rows rather than being highlighted. I did try doing them in orange like you'll see in the TRP stats, but didn't like the effect. On a conjecture project, green means we've found a prime while orange just means there are no candidates currently loaded. In TRP you'll see that some k's were tested to high n values for reasons I don't know  it was before my time. Now that I've been thinking about it, I see no reason to highlight a PPS k where we just happen to not have any candidates being tested right this moment.  


Now that I've been thinking about it, I see no reason to highlight a PPS k where we just happen to not have any candidates being tested right this moment.
Thanks, I think it's much less confusing like this. /JeppeSN  

KEPSend message
Joined: 10 Aug 05 Posts: 293 ID: 110 Credit: 9,443,250 RAC: 2,891

...In TRP you'll see that some k's were tested to high n values for reasons I don't know  it was before my time...
Well I happen to know the answer because I asked Rytis back then if we had found a prime. Matter of fact were that we had not and back then the decision had been to take two low weight k's to n=10M to see if we could find a big prime :)
Maybe in a future challenge, it could be wort pushing 13 low weight k's to n=50M or to n=25M? I might require a longer challenge, however it will make this project more interesting and it will give us the first conjecture k's that are fully tested to n=50M... just a thought that might be worth considering since a prime in the sub 50M territory will bring some attention and new users to Primegrid :)  

Michael GoetzVolunteer moderator Project administrator
Send message
Joined: 21 Jan 10 Posts: 13648 ID: 53948 Credit: 285,351,178 RAC: 47,109

Maybe in a future challenge, it could be wort pushing 13 low weight k's to n=50M or to n=25M? I might require a longer challenge, however it will make this project more interesting and it will give us the first conjecture k's that are fully tested to n=50M... just a thought that might be worth considering since a prime in the sub 50M territory will bring some attention and new users to Primegrid :)
Note that this is about TRP, not PPS
tl;dr: Sorry, but current management thinks this is a horrible idea. We consider prior deep searches on specific k's to have been a mistake which we're not likely to repeat.
There's two problems with this, and the only advantage is both very slight and irrelevant.
Problem one: The same amount of work needs to be done to find a prime in all the k's necessary to prove the conjecture, and it doesn't matter in what order you do the work. All you're accomplishing is adding complexity to the management of the project.
Problem two: Going to higher n's, and especially all the way to 50M, means longer tasks, and longer tasks mean more errors, longer timeouts, longer waits for wingmen, etc. It's better to push those tasks off into the future when we'll have faster CPUs.
Benefit: None, at least to LLR. But there is a theoretical benefit to sieving: Every k you eliminate makes sieving faster. However, for this to work you have to pick the correct k upon which to do a deep search. Otherwise, you're actually delaying removing a k, and hurting the sieve effort instead of helping it. The effect on the sieve is rather small, either way. And, of course, it's totally irrelevant now since we're done sieving TRP.
____________
My lucky number is 75898^{524288}+1  

Message boards :
Proth Prime Search :
Some k values (multipliers) are green? 