Message boards :
Sierpinski/Riesel Base 5 Problem :
Riesel k=3622 eliminated (outside PrimeGrid)
Author |
Message |
|
3622 · 5^7558139 - 1 - by Ryan Propper. | |
|
|
The exponent (n) in his find is about 7.6M. Currently our SR5 project is near 3.6M.
Does anyone know if he will take (has taken) other k from Riesel (or Sierpiński) base 5 this far as well?
/JeppeSN | |
|
compositeVolunteer tester Send message
Joined: 16 Feb 10 Posts: 1150 ID: 55391 Credit: 1,099,865,600 RAC: 803,287
                        
|
It looks like the way to go on this subproject is to pick a k and stick with it until a prime is found.
Running one k like this makes progress on that k around 30 or more times faster than spreading the work among all the k.
It doesn't reduce or increase the total work done, we are aiming to get all the k anyway.
To discourage someone from picking a k and hoping not to be duplicating work,
a k would be selected at random and a whole lot of tasks performed on that one k.
If no prime is found in, say 2 weeks, switch to another k.
This strategy requires encrypting the inputs to prevent someone from getting a work unit to see what's being worked on.
If a prime will never be eliminated, how soon will we give up? | |
|
|
In my opinion the order PrimeGrid does the SR5 search is good.
Propper can still find a prime by fixing one k and spending an extreme amount of crunching, and having luck. But that is not proof it is "better". Had he used the same computing power on all the k, he would likely have found more than one prime, but his finds would be smaller.
/JeppeSN | |
|
compositeVolunteer tester Send message
Joined: 16 Feb 10 Posts: 1150 ID: 55391 Credit: 1,099,865,600 RAC: 803,287
                        
|
In my opinion the order PrimeGrid does the SR5 search is good.
Propper can still find a prime by fixing one k and spending an extreme amount of crunching, and having luck. But that is not proof it is "better". Had he used the same computing power on all the k, he would likely have found more than one prime, but his finds would be smaller.
/JeppeSN
The only chance being taken here is that the conjecture isn't false.
It's just a question of time to a determined individual playing the long game.
Agreed, there's a trade-off of T5k quantity versus T5k rank, so it depends what you mean by "better".
The moonshot strategy is better for Propper as it puts him in the pilot's seat
with a strategy gives him an assured result for the investment.
He is currently 7th-ranked in RAC, so he can do extreme crunching.
He will test every candidate in a k first, to the exclusion of others, until one is found.
PG's current SR5 allocation strategy is better for PG - it maximizes the rate of prime finds in the short term.
Celebrating short term successes is good for team-building, and team effort is foundational to PG's success.
But no individual is assured of finding any prime, whatever resource the individual has - it's probabilistic.
These days anyone who doesn't want to be a team player can be the astronaut by buying the seat.
Don't mistake this post for bitterness.
Proper's strategy is unmistakeably robbing PG of primes because he's frontrunning in PG's range of k's.
It's not illegal. It doesn't prove the conjecture any sooner. And it's only slightly unethical from the PoV of wasted energy (Bitcoin is far worse).
I'm just stating the obvious, and proposing a way to disincentivize moonshots. | |
|
compositeVolunteer tester Send message
Joined: 16 Feb 10 Posts: 1150 ID: 55391 Credit: 1,099,865,600 RAC: 803,287
                        
|
On second thought, moonshots are fine.
It's frontrunning that needs to be discouraged.
PG could give Propper a k of his choice to moonshot, and we avoid that k.
But then someone with bigger resource could frontrun on Propper.
So the PG allocation would have to be secret.
And if double-checking a range is important, think about that.
So the proposal to scramble the input and do PG team mini-moonshots remains. | |
|
Michael Goetz Volunteer moderator Project administrator
 Send message
Joined: 21 Jan 10 Posts: 14011 ID: 53948 Credit: 435,849,066 RAC: 874,179
                               
|
On second thought, moonshots are fine.
It's frontrunning that needs to be discouraged.
PG could give Propper a k of his choice to moonshot, and we avoid that k.
But then someone with bigger resource could frontrun on Propper.
So the PG allocation would have to be secret.
And if double-checking a range is important, think about that.
So the proposal to scramble the input and do PG team mini-moonshots remains.
For the record, Propper is free to do whatever he wants to do, and he has a good reason for crunching outside of PrimeGrid. He has a lot of computing power that can not be connected to BOINC. Far from being upset about what he's doing, we're grateful for his help.
It's one less K we have to search.
____________
My lucky number is 75898524288+1 | |
|
compositeVolunteer tester Send message
Joined: 16 Feb 10 Posts: 1150 ID: 55391 Credit: 1,099,865,600 RAC: 803,287
                        
|
For the record, Propper is free to do whatever he wants to do, and he has a good reason for crunching outside of PrimeGrid. He has a lot of computing power that can not be connected to BOINC.
Fair enough.
Far from being upset about what he's doing, we're grateful for his help.
It's one less K we have to search.
I'm glad you set that straight.
He has explained that he is trying to avoid interfering with PG (k,n) ranges.
So as long as we're not repeating work, it's fine - there are no wasted CPU cycles.
The onus here is on PG to not search in a previously worked range.
Here's hoping that Propper eliminates a k before PG has to adjust it's range.
If someone could magically predict which n will have a prime for a given k, we would all be crunching a lot less. | |
|
GDBSend message
Joined: 15 Nov 11 Posts: 298 ID: 119185 Credit: 4,070,818,585 RAC: 1,963,438
                      
|
How does this affect Base 5 searching?
Will this k be removed from PG?
Or will we continue searching this k, to find a smaller prime?
____________
| |
|
Michael Goetz Volunteer moderator Project administrator
 Send message
Joined: 21 Jan 10 Posts: 14011 ID: 53948 Credit: 435,849,066 RAC: 874,179
                               
|
How does this affect Base 5 searching?
Will this k be removed from PG?
Or will we continue searching this k, to find a smaller prime?
We have removed this K from out search.
____________
My lucky number is 75898524288+1 | |
|
|
We have removed this K from out search.
This can also be seen from https://www.primegrid.com/stats_sr5_llr.php (blue row near the top). The page takes a few moments to load, in my experience. /JeppeSN | |
|
Crun-chi Volunteer tester
 Send message
Joined: 25 Nov 09 Posts: 3233 ID: 50683 Credit: 151,443,349 RAC: 54,956
                         
|
How does this affect Base 5 searching?
Will this k be removed from PG?
Or will we continue searching this k, to find a smaller prime?
We have removed this K from out search.
So PG is abandoned the strategy that must be found smallest possible prime of any K? ( or it was only discussion of PG need to do remain candidates ( when he or someone else find also prime in SR5)
____________
92*10^1585996-1 NEAR-REPDIGIT PRIME :) :) :)
4 * 650^498101-1 CRUS PRIME
2022202116^131072+1 GENERALIZED FERMAT
Proud member of team Aggie The Pew. Go Aggie! | |
|
Michael Goetz Volunteer moderator Project administrator
 Send message
Joined: 21 Jan 10 Posts: 14011 ID: 53948 Credit: 435,849,066 RAC: 874,179
                               
|
How does this affect Base 5 searching?
Will this k be removed from PG?
Or will we continue searching this k, to find a smaller prime?
We have removed this K from out search.
So PG is abandoned the strategy that must be found smallest possible prime of any K? ( or it was only discussion of PG need to do remain candidates ( when he or someone else find also prime in SR5)
Yes. Our goal is to prove the conjecture. For Ks that we eliminate, we will continue to prove that those are the lowest primes. Ks eliminated by other people won't be tested by us.
____________
My lucky number is 75898524288+1 | |
|
Jay Send message
Joined: 27 Feb 10 Posts: 132 ID: 56067 Credit: 64,433,752 RAC: 10,168
                    
|
Yes. Our goal is to prove the conjecture. For Ks that we eliminate, we will continue to prove that those are the lowest primes. Ks eliminated by other people won't be tested by us.
When PrimeGrid eliminates a K, does proving it's the lowest prime go to the lowest of the priority list? Seems like those are resources that could be used to eliminate the next K. Proving it's the lowest has nothing to do with the conjecture. Could that work be postponed for a separate subproject? Or is the amount of work left to prove it's the smallest prime something like less than 2-3 days worth?
Is the same strategy applied to SOB? I'm in this to prove conjecture(s). I'd rather be on the front lines of the attack. | |
|
Michael Goetz Volunteer moderator Project administrator
 Send message
Joined: 21 Jan 10 Posts: 14011 ID: 53948 Credit: 435,849,066 RAC: 874,179
                               
|
Yes. Our goal is to prove the conjecture. For Ks that we eliminate, we will continue to prove that those are the lowest primes. Ks eliminated by other people won't be tested by us.
When PrimeGrid eliminates a K, does proving it's the lowest prime go to the lowest of the priority list? Seems like those are resources that could be used to eliminate the next K. Proving it's the lowest has nothing to do with the conjecture. Could that work be postponed for a separate subproject? Or is the amount of work left to prove it's the smallest prime something like less than 2-3 days worth?
Is the same strategy applied to SOB? I'm in this to prove conjecture(s). I'd rather be on the front lines of the attack.
Since we work from the bottom up, when we find a prime, nearly all the work to prove it's the lowest prime is already done. All that's necessary is to finish off the candidates that are already in the process of being tested. Little to no extra work is required.
However, when someone else finds a prime at a much higher N than where we're testing, a substantial amount of work would be required to prove it's the lowest prime. We're not doing that.
It's the same for all the conjectures.
____________
My lucky number is 75898524288+1 | |
|
Jay Send message
Joined: 27 Feb 10 Posts: 132 ID: 56067 Credit: 64,433,752 RAC: 10,168
                    
|
Since we work from the bottom up, when we find a prime, nearly all the work to prove it's the lowest prime is already done. All that's necessary is to finish off the candidates that are already in the process of being tested. Little to no extra work is required.
However, when someone else finds a prime at a much higher N than where we're testing, a substantial amount of work would be required to prove it's the lowest prime. We're not doing that.
It's the same for all the conjectures.
That makes sense. Thanks for the extra info! | |
|
|
On second thought, moonshots are fine.
It's frontrunning that needs to be discouraged.
PG could give Propper a k of his choice to moonshot, and we avoid that k.
But then someone with bigger resource could frontrun on Propper.
So the PG allocation would have to be secret.
And if double-checking a range is important, think about that.
So the proposal to scramble the input and do PG team mini-moonshots remains.
For the record, Propper is free to do whatever he wants to do, and he has a good reason for crunching outside of PrimeGrid. He has a lot of computing power that can not be connected to BOINC. Far from being upset about what he's doing, we're grateful for his help.
It's one less K we have to search.
I agree with you, he helps Primegrid. But I have a stupid question that maybe could solve some problems. For some projects it should be important to find the smallest prime but I suppose that sometimes, Propper is crunching some K without finding a prime.
It will be very interesting for Primgrid to get all the computation residue. So we can just do the double check on some range or with LLR2 do the verification.
So Primegrid could resume were Propper stop the search on some K, or skip the range when we reach it.
Do you think this is possible to get the residue?
Thanks
____________
Badge Score: 1*4 + 1*5 + 7*6 + 8*7 + 3*8 + 1*9 = 140 | |
|
Michael Goetz Volunteer moderator Project administrator
 Send message
Joined: 21 Jan 10 Posts: 14011 ID: 53948 Credit: 435,849,066 RAC: 874,179
                               
|
On second thought, moonshots are fine.
It's frontrunning that needs to be discouraged.
PG could give Propper a k of his choice to moonshot, and we avoid that k.
But then someone with bigger resource could frontrun on Propper.
So the PG allocation would have to be secret.
And if double-checking a range is important, think about that.
So the proposal to scramble the input and do PG team mini-moonshots remains.
For the record, Propper is free to do whatever he wants to do, and he has a good reason for crunching outside of PrimeGrid. He has a lot of computing power that can not be connected to BOINC. Far from being upset about what he's doing, we're grateful for his help.
It's one less K we have to search.
I agree with you, he helps Primegrid. But I have a stupid question that maybe could solve some problems. For some projects it should be important to find the smallest prime but I suppose that sometimes, Propper is crunching some K without finding a prime.
It will be very interesting for Primgrid to get all the computation residue. So we can just do the double check on some range or with LLR2 do the verification.
So Primegrid could resume were Propper stop the search on some K, or skip the range when we reach it.
Do you think this is possible to get the residue?
Thanks
The residues wouldn't help. We use LLR2 with fast DC, and only need to run the test once.
If he gives us the residues, we need to run the test ... once, on LLR.
If he doesn't give us the residues, we need to run the test ... once, on LLR2, plus the fast DC task.
The savings are minimal and not worth the trouble. If we wanted to check that he didn't miss anything, it's essentially the same as just running it ourselves in full.
And, no, he can't run LLR2 and then we run the fast DC tasks. There's encryption issues, plus a truly massive amount of files that need to be stored.
____________
My lucky number is 75898524288+1 | |
|
|
Thanks for the explanation. Too bad.
____________
Badge Score: 1*4 + 1*5 + 7*6 + 8*7 + 3*8 + 1*9 = 140 | |
|
Message boards :
Sierpinski/Riesel Base 5 Problem :
Riesel k=3622 eliminated (outside PrimeGrid) |