![]() |
|
|
#441 | |
|
"Serge"
Mar 2008
Phi(4,2^7658614+1)/2
9,497 Posts |
Quote:
|
|
|
|
|
|
|
#442 | |
|
6809 > 6502
"""""""""""""""""""
Aug 2003
101×103 Posts
22·23·107 Posts |
Quote:
Last fiddled with by Uncwilly on 2013-10-14 at 00:00 |
|
|
|
|
|
|
#443 |
|
"Bill Staffen"
Jan 2013
Pittsburgh, PA, USA
23×53 Posts |
My concern is your concern, Uncwilly, I only work in this area for you.
![]() Though last I checked you preferred me to work on the lowest numbers in the range up to 79, which would dominate that number. I'm more than happy to work in higher ranges (right 2/5 of the graph) if you think that would help the project more. |
|
|
|
|
|
#444 |
|
"Richard B. Woods"
Aug 2002
Wisconsin USA
11110000011002 Posts |
What helps the project most is letting each assignee work on his/her own assignment without poaching. That's the most efficient and fastest way forward.
Worrying about "milestones" or bit levels in particular ranges is taking ones attention off the overall collective progress, and tempts one to poach, which can only slow down GIMPS, never speed it up. In the long run, every milestone and every bit level is eventually achieved. Obsessing about the imagined short-run "slowness" of one particular measure can lead to forgetting about progress on other measures. If one wants some particular measure to advance more rapidly, the way to do it is to work on ones own assignments that affect that measure, not take over someone else's assignment. If, however, all the assignments that could affect some measure (such as TFing all exponents with a 5, but not a 4, in their decimal form, to 128.2 bits) are already assigned to other folks, then let them do that work, and go do some other available assignment instead of interfering with them. Last fiddled with by cheesehead on 2013-10-16 at 21:23 |
|
|
|
|
|
#445 |
|
"Bill Staffen"
Jan 2013
Pittsburgh, PA, USA
23·53 Posts |
I don't need the lecture, Cheese. Those candidates that need factored aren't being factored, and factoring them doesn't take away the work of the person doing the LL test. The LL test is the only reason they're not being assigned to be factored.
|
|
|
|
|
|
#446 | ||
|
"Richard B. Woods"
Aug 2002
Wisconsin USA
22·3·641 Posts |
Apparently, you _do_ actually need a reminder of reasons for not working on an exponent that's already been assigned for L-L by someone else.
Quote:
If you already knew that ... Would your non-harm policy be to report unsuccessful factoring attempts, but ... do what when the factoring succeeds in finding a factor while someone else toils away at the LL test -- suppress reporting successful factoring? If so, then when do you eventually report the found factor? Or do you intend to just discard factors you find when you shouldn't have been searching for them? Or do you just not give a damn about someone else's credit for toiling away at the LL assignment in good faith? You seem to have forgotten that GIMPS's purpose for doing factoring on exponents in ranges about to be assigned for L-L (or higher) is to save the work of doing the L-L test. That only works when it actually prevents the L-L test from being assigned, not when the L-L has already been assigned. Quote:
Factoring to 79 bits is not an end in itself; it's just a measure to try to prevent needing to do the L-L. Once the L-L has been assigned, there is no GIMPS-related "need" to do further factoring. Please keep your priorities straight. (Note that I've been speaking of exponents in or near the range of current or recently-past LL assignments. Small exponents (say, < 1M) have already provided their L-L testers with a credit for several years.) Last fiddled with by cheesehead on 2013-10-17 at 05:23 |
||
|
|
|
|
|
#447 |
|
May 2013
East. Always East.
11×157 Posts |
The only reason to factor and primality test at the same time is if you're hunting for the actual factors for some reason, but I think the full decomposition of Mersenne numbers is kept to the < 10M range and even then is a wild goose chase in my opinion.
Cheesehead hit it perfectly. Factoring saves LL tests and that's it. There's no reason to save an LL test if it is in progress. Of course, I will disagree with the idea of doing an LL test on a 100-million digit exponent in the first place. They just take so damn long to run (~5,000 GHz-Days is about a year on a high-end CPU with overclocking). To each their own, of course. |
|
|
|
|
|
#448 | |
|
If I May
"Chris Halsall"
Sep 2002
Barbados
2×67×73 Posts |
Quote:
I will agree, however, that it's a bit of a waste of resources. |
|
|
|
|
|
|
#449 | |
|
"Richard B. Woods"
Aug 2002
Wisconsin USA
22·3·641 Posts |
Quote:
Seems like a mistake that needs correcting, or else we'll get a diversion of LL effort to exponents that have already been proven composite by factoring. Or there could be another type of credit given: uselessly LLed Last fiddled with by cheesehead on 2013-10-17 at 14:34 |
|
|
|
|
|
|
#450 | |
|
If I May
"Chris Halsall"
Sep 2002
Barbados
2·67·73 Posts |
Quote:
But, at the end of the day, everyone's welcome to do whatever they want with their own time, kit and power bills, so long as it doesn't have a negative impact on the project. |
|
|
|
|
|
|
#451 | |
|
Aug 2010
Kansas
22316 Posts |
Quote:
Of course, my goal has always been to eliminate candidates, so I prefer doing whichever is cheaper in terms of electricity usage per candidate... |
|
|
|
|
![]() |
Similar Threads
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| GPU72 / MISFIT use for 100M digit range? | Uncwilly | GPU to 72 | 64 | 2013-03-31 02:45 |
| I want a 100M digit Mersenne that.... | JuanTutors | PrimeNet | 8 | 2012-12-06 13:47 |
| How far along are you in your 100M digit LL test? | JuanTutors | Lounge | 6 | 2012-02-21 07:36 |
| 100M-digit n/k pairs | __HRB__ | Riesel Prime Search | 0 | 2010-05-22 01:17 |
| 100M digit prime | Unregistered | Information & Answers | 10 | 2010-03-24 20:16 |