Re: Mersenne: On v18 factoring
Daran - you ask why highest and not lowest? The discussion started regarding old machines running v18 which are no longer in the care, custody control of an active GIMPS participant, AND which are asking for factoring assignments which they cannot handle. Whatever assignment is given to them, there is no telling how long until (or even if) they will finish it. We would not want to give them something that would hold up a milestone a year or so down the road. So I agree with Brian, give them the highest available (I don't mean 33M) which will keep them busy for a while, but probably on the order of a year rather than a few months. If it takes them a year and a half to finish, no problem; if it stops running then it goes back to the server, again no problem. As for runaway v18 clients asking for DCs, they would continue getting what they ask for. You make a good point about P-1 completed assignments, but on further reflection I don't think that is necessary. There aren't that many available and certainly not at the higher end of the current range. They will more than likely be P-1 tested when double-checked. Steve -Original Message- From: Daran [EMAIL PROTECTED] To: [EMAIL PROTECTED] [EMAIL PROTECTED] Date: Thursday, October 24, 2002 4:37 AM Subject: Re: Mersenne: On v18 factoring - Original Message - From: Brian J. Beesley [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, October 23, 2002 7:52 AM Subject: Re: Mersenne: On v18 factoring Given that the server can tell the difference between a v18 client and a later one, would it not make most sense to have the server assign a LL test on the _highest_ unallocated exponent which v18 can handle if a v18 client asks for a factoring assignment and none suitable are available. This action would effectively remove the client from the loop for a while (probably a few months, given that most v18 clients will be running on slowish systems), thereby alleviating the load on the server, and buying time to contact the system administrator - when this is still relevant, of course. And some useful work may still be completed, eventually! Why highest? Why not give it the lowest? There's a case for only giving version 18 and below clients DCs regardless of the work requested. (I'm assuming that this is possible.) The only other point I'd add, which isn't particularly relevent to this question, is that these clients should always be given P-1 complete assignments if available. Regards Brian Beesley Daran G. _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Order of TF and P-1
I don't think the TF limits were ever lowered; it seems they may have been raised, as I have gotten several 8.3M DC exponents which first had to be factored from 63 to 64 and THEN the P-1. It occurred to me that it might be more efficient to do it the other way around, but factoring from 63 to 64 goes relative quickly. If it were a question of factoring from 65 to 66 versus P-1 first, then I think the P-1 wins easily. Steve -Original Message- From: Daran [EMAIL PROTECTED] snip When the TF limits were originally decided, it was assumed that a sucessful TF would save 1.03 or 2.03 LLs. I can't remember whether George has ever said whether they have been lowered to take the P-1 step into account. Daran G. _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Error message from prime95 on an old Win95 box
Sounds like the opposite problem: Prime95 is trying to delete a registry entry that doesn't exist. I had one do that to me recently. Rather than uncheck the box, manually edit ( in prime.ini ) the line windows service=1 (or whatever line it has to that effect) to ...=0 and it will no longer see a need to try to delete the registry entry. And the box will now show as unchecked. Hope that helps, Steve Harris -Original Message- From: A T Schrum [EMAIL PROTECTED] Date: Wednesday, July 17, 2002 5:26 PM No go. The box was unchecked. I checked it, restarted Prime95, and the error message was not there. So I unchecked it, restarted Prime95, and the error message came back. George Woltman wrote: At 09:34 PM 7/16/2002 -0400, A T Schrum wrote: I didn't find a reference to this problem. My old PentiumMMX 200 Mhz box running Win95 OSR2 (with tons of patches) now has Prime95 2.26.1 on it and it runs reasonably faster (about 20ms faster at 768K FFT size). But upon startup, Prime95 reports Can't write registry value and continues on. Should I be concerned? I doubt it. Prime95 should be trying to create a registry entry to run the program at bootup. If you uncheck the Options/Start at Bootup menu item the problem should go away. I'm curious though. Do other Win95 users have the same trouble? _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: A runaway P95 install script?
The default for either network retries or modem retries (I forget which, big surprise) is 2 minutes. If there is a communications problem with the machine (asking for exponents but not receiving them for some reason), that would explain the timing. Also, if the machine is running unattended and no one is checking the account status, then it could go on for a very long time. -Original Message- From: Mary K. Conner [EMAIL PROTECTED] Date: Friday, March 22, 2002 12:52 AM It seems to be reserving one exponent every 2 minutes. Since a malicious person could reserve exponents much faster, and would probably not be so steady over so many hours doing it by hand, I suspect it is a matter of a Prime95 process that has lost access to its disk space, thinks it has no work, and keeps downloading exponents, trying to save them, and then noting two minutes later (perhaps the timeout for a Windows share or other network mounted space) that it either has no worktodo, or the worktodo is empty, and looping. It is odd that it has gone on for so long though. _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Factors aren't just factors
Don't be so hard on Phil, I made not only a mistake but one that was very easy to catch. I should know by now better than to trust my memory before sending something out. But it's hard to get used to being senile :-) I guess that also explains why I never pursued it... Steve -Original Message- From: Torben Schlüntz [EMAIL PROTECTED] To: Phil Moore [EMAIL PROTECTED]; [EMAIL PROTECTED] [EMAIL PROTECTED] Date: Wednesday, March 20, 2002 4:41 PM Subject: SV: Mersenne: Factors aren't just factors Actually I should have let Steve answer this, but I can't ignore to say that I already have pointed out that M89 is prime. So Steve had a mistake. Okay?! I do several mistakes every hour. snip _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Factors aren't just factors
Torben, I noticed something along those lines long ago: the first non-prime
Mersenne number is M11 which factors to 23 times 89. The very next non-prime
Mersenne number is M23, and M89 is also not prime. It occurred to me then
that possibly Mx is never prime if x is a factor of a Mersenne number, but
it was just an observation and I never got around to pursuing it. If so,
then it would (although only very slightly) reduce the number of candidates
to be tested. So I am just as curious as are you.
Jeroen, I am wondering about your phrase if kv is not prime then 2^(kv)-1
isn't also because kv is never prime, it has factors k and v (unless k=1,
of course), and 2^(kv)-1 always has factors 2^k-1 and 2^v-1. I don't know if
you meant something else or if I just misunderstood you. Sorry if that's the
case.
Regards,
Steve Harris
-Original Message-
From: Jeroen [EMAIL PROTECTED]
To: [EMAIL PROTECTED] [EMAIL PROTECTED]
Date: Tuesday, March 19, 2002 8:12 PM
Subject: Re: Mersenne: Factors aren't just factors
to find the value v where prime p is a factor of 2^v-1
tempvalue = p
count = 0
while tempvalue != 0
{
if tempvalue is odd
{
shiftright tempvalue
count++
}
else
{
tempvalue+=p
}
}
if the count is a primenumber then p is thus a factor of a mersenne prime
if the count is not a primenunber it isn't
if p is a factor of 2^v-1 then it is also a factor of 2^(2v)-1
or just 2^(kv)-1 for all value of k are integers above 0
if kv is not prime them 2^(kv)-1 isn't also, so each prime can only be a
factor of one mersenne numer or 0 mersenne numbers
the first question is now simple to solve, just find the 2^v-1 where Mx is
a factor of
*** REPLY SEPARATOR ***
On 20-3-02 at 0:21 Torben Schlüntz wrote:
Just of curiosity:
Has it ever happened that a factor for Mx later has proved to be a
mersenne prime itself?
Has the same factor been a factor for two different Mx and My?
In my humble oppinion both questions answers No; but GIMPS could have
proved otherwise.
Anyway, it must exist a great deal of low primes; which by now never can
become mersenne factors (by reason: 2kp+1). So with two types of primes,
those that are mersenne factors and those that never can be, do we have
any means of distinguish them?
Happy hunting
tsc
Btw: (M29 mod 1 + M29 mod 2 +..+ M29 mod 32) = 233which is 1.
factor of M29
_
Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
_
Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
_
Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: LL test efficiency
On Friday 1 March 2002 15:31, Brian J. Beesley wrote: On reflection I can see that there is merit in Steve's idea (provided that restraint is used i.e. not grabbing more work than is neccessary to bridge the rather small exponent gap). Thanks, Brian. I probably should have mentioned in my original message that it should only take about 10-12 days for the Primenet server to hand out all the assignments in that range (15.16M to 15.30M). Regards, Steve Harris _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: LL test efficiency
For those of you interested in optimizing efficiency of LL testing: We are approaching first time tests of 15.30M exponents, at which point the Prime95 program will start using an 896K FFT. However, the P4-SSE2 section of the program will start using that larger FFT size at 15.16M exponents, making it (relatively) inefficient to test exponents between 15.16M and 15.30M on a P4. Since the Primenet server doesn't take this into consideration when assigning exponents, I would suggest you all have enough exponents queued up on your P4s before the server reaches 15.16M to keep them busy until it reaches 15.30M. I know there are other ways around it, but that is the simplest. Steve Harris _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Are problems more likely in the last 1% of a 10,gigadigit LL?
-Original Message- From: Russel Brooks [EMAIL PROTECTED] How about a Prime95 option where it makes a daily backup for you, saved to a datestamp fileid? It could save them to a subdirectory with the exponent name. That would make it easy for the user to do a cleanup occasionally. There is already a feature which does effectively the same thing. Set 'InterimFiles=100' in prime.ini and it will write a save file in the working directory with a sequential extension every million iterations (or however often you set it). You must manually edit the prime.ini file, it's not a menu option. It's still a good idea to back up the savefile to some other medium every so often in case you lose your whole hard drive. Regards, Steve Harris _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: slaying cpus with prime95
As others have already mentioned, those machines would probably have died even without Prime95. The way I have always looked at it, Prime95 generally causes those types of (pre-existing) problems to manifest _before_ the warranty expires, rather than after. This feature is certainly not a Bad Thing :-) Steve Harris -Original Message- From: Steve Elias [EMAIL PROTECTED] Date: Monday, January 14, 2002 1:58 PM Subject: Mersenne: slaying cpus with prime95 here are some instances where i have damaged computers by (capriciously?) running prime95! 1 - i just got my wife's toshiba laptop back from toshiba warranty service. running prime95 for ~6 months on it caused the fan to die, and then the laptop would overheat shutdown even without prime95 running. apparently the heat caused lots of disk badblocks too. 2 - my manager at work here had a thinkpad. he ran prime95 despite my worry that it was very tough on laptops. within a few months his harddrive failed - possibly due to months of excess heat... :| this could be considered a classic Dilbertian CLM (career limiting move) on my part, but no worry since my manager is super-cool. 3 - i also ran the prime95 app for a year or so on an ancient cyrix p120+ which had a cpu-fan that stopped. after a couple months of no-cpu-fan, that cpu died completely... 4 - i bought a 2Ghz P4 recently. despite initial worries that it was running too hot (70 C) because fan was too slow (2800 rpm), i got adventurous and clocked the cpu at 2.1 Ghz for a day. weeks later the machine started acting very badly (motherboard cpu temp alarm caused shutdown @ 90 C even without prime95 running). so i returned it to the vendor. they claimed that my overclocking it broke the P4, and that the top of the cpu was actually burnt/blackened from the heat. this is counter to my belief that improper fan/heatsink was the cause, but i can't prove it. also it runs counter to what i've read here elsewhere about the thermal-protection built into P4s 1.7Ghz or faster. they are returning the P4 to intel to see if Intel will replace it for free, but in the meantime i have to pay for a new cpu! (i'm picking 1.8Ghz this time.) so far my count is 4 for computers i've damaged with the help of the the prime95 application. but i'll keep running it because it is the coolest application around (in a hot way). /eli _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Prime freezing when connecting by DSL to Primenet
Interesting... I have had that happen to me as well a few times with PCs on a DSL (but without AOL). It doesn't happen on a regular basis but does lock up the program (v21.3) for hours or days at a time. Just caught one today that had been stuck like that for seven hours, even 'end task' couldn't stop it. I had to reboot the PC, then it connected and reported in just fine immediately afterwards. Irv, I know this is no help, except to let you know you aren't the only one... Steve Harris -Original Message-From: [EMAIL PROTECTED] [EMAIL PROTECTED]Date: Friday, January 11, 2002 10:58 PMSubject: Mersenne: Prime freezing when connecting by DSL to PrimenetI am running version 21.4 of Prime. I recently started using a DSL connection on AOL. ( I am using Version 7.0 of AOL). Since I started using this arrangement, Prime locks up whenever it connects with Primenet. After some delay, during which time everything stops, Primenet reports an ERROR 12031. The only way that I can successfully report to Primenet, is to connect to AOL using my modem.This problem occurs when reporting results, getting new exponents and reporting expected completion dates.Any suggestions? I can give more details if needed.Irv Rosenfeld
Re: Mersenne: Re: Munich prime party report
EWMAYER wrote: Personally, I don't think there's anything special about a ratio of 2. Certainly not, but perhaps there may be something special about 2.1025, which is 1.45^2 ? At any rate, the sample size is far too small to ascertain a good standard deviation, or to validate any hypotheses. And I think I'll use Zecher for my next machine ID; thanks for the tip :-) Ian Halliday wrote: ...note that the exponents of M(13) and M(14) differby more than a factor of 2, as do the exponents of M(15) and M(16).Similarly for M(35) and M(36) with M(37) and M(38). I don't believe the 13-14 and 15-16 gaps are 2; still, you are correct about 35 to 38. But the 36-37 gap has a ratio of only 1.015, which is extremely small. [I recall that Roland Clarkson said he almost returned the M(37) exponent to the server as it was so close to M(36).] I have mentioned here before that the large gaps tend to be adjacent to the small gaps, which is to be expected if the overall distribution is to remain around the average of 1.45 - but this cannot be counted on. Alex Kruppa wrote: next on schedule, if Steve can make it in March, is eineMa, Starkbier and Nockherberg! :) I am already completely familiar with both the Ma and Starkbier, even to the point of eine Starkbier Ma What better reason to go to Munich after Fasching! (I hope that does not further tarnish the reputation of mathematicians with Daidalos :-) Happy new year, Steve Zecher Harris
Mersenne: Munich prime party report
We finally got the picture, text, and translations approved by all involved, so here is our report on the Munich chapter of the prime party of 7 december (at least as much as we can remember) : http://www.sheeplechasers.org/prime/muenchen/ In case there is no new mersenne prime found in the near future, we plan to make this an annual event - or semiannual, or quarterly, or however often we can get together. We did decide that making it a daily event was totally out of the question :-) Happy holidays, Steve ( Alex) _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Re: Factoring benefit/cost ratio
Richard, Your first interpretation of verified residues is correct, they are retested until two residues match. Any time a double-check reports in a residue which is different from the first LL test, the exponent is returned to the database to be tested again. This means that at least one of the residues is incorrect, and happens (relatively) often, I believe about two percent of the time. However, as has been pointed out before, the odds of two LL tests on different machines returning the _same_ incorrect residues are astronomical (although, of course, still non-zero). Steve -Original Message- From: [EMAIL PROTECTED] [EMAIL PROTECTED] To: [EMAIL PROTECTED] [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] [EMAIL PROTECTED] Date: Wednesday, December 05, 2001 8:34 PM Subject: Re: Mersenne: Re: Factoring benefit/cost ratio Brian, I'm wondering whether we may be misunderstanding each other's contentions here. I thought you object to at least some of what I claimed, but now it seems that you're presenting arguments and evidence that support what I'm claiming. Since my previous postings may have had careless wording or otherwise obscured my intentions, and I did not earlier realize the importance of certain details to the discussion, let me restate what I've meant to claim: 1. It is more valuable to know a specific factor of a Mnumber than to know that that Mnumber is composite without knowing any specific factor. (There's little dispute about #1.) 2. Claim #1 is true not only from the viewpoint of mathematics in general, but also from the narrower viewpoint of the GIMPS search for Mersenne primes. 3. One (but not the only) justification for claim #2 is that, _in current practice_, a composite status derived by GIMPS from finding a specific factor is (slightly) more reliable than a composite status derived by GIMPS from matching nonzero residues from Lucas-Lehmer tests. That is, although in theory, or ideally, those two methods of determining compositeness are equally reliable, there currently exists a slight difference in reliability, in favor of the factor, from a practical standpoint. 4. Our experience (the record), as documented in the Mersenne mailing list or GIMPS history, supports claim #3. - - - - - Brian Beesley wrote: AFAIK our record does _not_ show any such thing. Oh? It doesn't? There is no evidence of any verified residuals being incorrect. Wait a second -- just yesterday you wrote that you had triple-checked thousands of small exponents (which means they had already been double-checked) and that A very few (think fingers of one hand) instances of incorrectly matched residuals have come to light - completing the double-check in these cases proved that one of the recorded residuals was correct. So it seems that the meaning you're assigning to verified is something like retested and retested until two residuals match. Is that a correct interpretation? If not, what is? My claim #3 means that in practice, factors require fewer verification runs to produce matching results than do L-L residues, on average. Do you disagree with that? If not, then don't we agree about claim #3? Furthermore, my claim #4 means that the demonstration that factors require fewer verification runs to produce matching results than do L-L residues, on average, rests on the observed history _including the paragraph you wrote from which I just quoted above!_ Do you disagree? Also, in that same paragraph you wrote, ... - some of the ones where the accepted residual was recorded to only 16 bits or less, which makes the chance of an undetected error _much_ greater (though still quite small) ... Am I correct in interpreting this to mean that you think that using 64-bit residuals is more reliable than using 16-bit residuals? If so, then surely you'll grant that 256-bit residuals would be even more reliable yet, meaning that there's still room for error in our practice of using 64-bit residuals. But a specific factor is a _complete value_, not some truncation, and so its reliability is not damaged by the incompleteness which you admit keeps the L-L residues from being totally reliable - right? Then you wrote so far no substantive errors in the database have come to light, but seemingly contradicted that in the very next sentence, A very few (think fingers of one hand) instances of incorrectly matched residuals have come to light - completing the double-check in these cases proved that one of the recorded residuals was correct. ... And thus _the other_ recorded residual was _incorrect_. Neither is there any evidence that any verified factors are incorrect. Depends on the meaning of verified, of course. :-) Will Edgington (I think) has reported finding errors in his factor data base ... even though he verifies factors before adding them. Mistakes happen. But I think the error rate for factors has been significantly lower than for L-L residuals. Whatever theory states, the experimental evidence
Re: Mersenne: Re: Factoring benefit/cost ratio
George did say that, and I was aware of his statement, but that still has no effect on the point I was making. George's GIMPS stats also give no credit at all for finding factors, but that doesn't mean he considers finding factors worthless. Steve -Original Message- From: Gerry Snyder [EMAIL PROTECTED] To: mer [EMAIL PROTECTED] Date: Saturday, December 01, 2001 12:19 PM Subject: Re: Mersenne: Re: Factoring benefit/cost ratio Steve Harris wrote: Actually, Richard's statement that a 'Factored' status is better for GIMPS than a 'Two LL' status is not quite true. It's better for the mathematical community as a whole, but not for GIMPS. GIMPS is looking for primes, not factors, and without skipping over any. Hmmm, I must be having a senior moment. I would swear George said that one way a person could lose credit for a correct LL test is if later factoring finds a factor. Is my feeble brain making this up, or is finding a factor more important than stated above? Gerry -- mailto:[EMAIL PROTECTED] Gerry Snyder, AIS Director Symposium Chair, Region 15 RVP Member San Fernando Valley, Southern California Iris Societies in warm, winterless Los Angeles--USDA 9b-ish, Sunset 18-19 my work: helping generate data for: http://galileo.jpl.nasa.gov/ _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: Re: Factoring benefit/cost ratio
Actually, Richard's statement that a 'Factored' status is better for GIMPS than a 'Two LL' status is not quite true. It's better for the mathematical community as a whole, but not for GIMPS. GIMPS is looking for primes, not factors, and without skipping over any. This means all candidates must be tested and the non-primes eliminated, and it doesn't matter whether they are eliminated by 'factored' or by 'two matching nonzero LL residues'. It matters to those who are attempting to fully factor Mersenne numbers, but that's a different project altogether, and one that is decades (at least) behind GIMPS. The only reason we do any factoring at all is to reduce the time spent on LL testing. Besides, if you do manage to find a 75-digit factor of a 2-million-digit Mersenne number, that still leaves a 125-digit remainder. Really not much help :-) Regards, Steve Harris -Original Message- From: Daran [EMAIL PROTECTED] To: [EMAIL PROTECTED] [EMAIL PROTECTED] Date: Friday, November 30, 2001 2:00 AM Subject: Re: Factoring benefit/cost ratio (was: Mersenne: Fw: The Mersenne Newsletter, issue #18) - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, November 24, 2001 6:49 PM Subject: Factoring benefit/cost ratio (was: Mersenne: Fw: The Mersenne Newsletter, issue #18) But ones factoring benefit calculation might [should would be in line with the popular theme of prescribing what's best for other GIMPS participants :)] include not only the time savings of eliminating the need for one or two L-L tests, but also the extra benefit of finding a specific factor. I can see no way of objectively quantifying this benefit. In the GIMPS Search Status table at www.mersenne.org/status.htm the march of progress is from Status Unknown to Composite - One LL to Composite - Two LL to ... Composite - Factored. More desireable - whether or not recorded on that page - would be Composite - Least (or greatest) factor known. Most desireable (other than Prime) would be Composite - Completely factored'. This reflects the view (with which I agree) that it is more valuable to know a specific factor of a Mnumber than to know that a Mnumber is composite but not to know any specific factor of that Mnumber. So a Factored status is better for GIMPS than a Two LL status, but calculations of factoring benefit that consider only the savings of L-L test elimination are neglecting the difference between those two statuses. If one consciously wants to neglect that difference ... well, okay ... but I prefer to see that explicitly acknowledged. It seems to be implicitely acknowledged in the way the trial factoring depths are determined. If one places a non-zero value on a known factor, then the utility of extra factoring work on untested, once tested, and verified composites would be increased. It would have to be set very high indeed to make it worth while returning to verified composite Mersennes. Richard Woods Daran G. _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers _ Unsubscribe list info -- http://www.ndatech.com/mersenne/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: number of processors participating
Henk, I don't have a consistent set of statistics, but I do save the world test status page every few months. So I can tell you that on 2-apr-2001 it showed 38652 machines on 20983 accounts, and right now it shows 30186 machines on 15659 accounts. I'm sure I didn't just happen to catch it at its peak; I recall there being over 21000 accounts at one time. WRT team '.', I recall a few months ago it seemed to be holding up some double-checks at the low end of the assignments, but it did eventually complete them all. Steve Harris -Original Message- From: Henk Stokhorst [EMAIL PROTECTED] To: [EMAIL PROTECTED] [EMAIL PROTECTED] Date: Saturday, October 27, 2001 1:20 PM Subject: Mersenne: number of processors participating L.S., I read a message some time ago on this list that claimed that the number of processors had gone down by about 9000. I don't have stats on this other than the actual available from the status pages. Does anyone have stats over the last year, like numer of pc's and/or processor types, processor speeds? If there would really have been a decrease in participating processors, (I don't think so) an updated graph of Primenet throughput would show by now, is there any update in the pipeline? I went through the status.txt file to see if the new 'stress test' button could have played a significant role, I don't think so. By the way if one runs prime95 without a user name the application fills in an S0 as user name. I found 3170 entries with a name '.' (only a dot) The fast majority of these entries seem to be have been abandoned. They have been reserved over a long time with a constant daily flow. Does anyone know more about this? YotN, Henk Stokhorst _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: AW: Mersenne: Prime Net Server
-Original Message- From: [EMAIL PROTECTED] [EMAIL PROTECTED] Date: Monday, September 10, 2001 1:58 AM BTW some people claim that the PrimeNet server is working, just very, very slowly. In that case it's more than likely that the server is sufferring a DoS attack :( That was my first thought. Isn't mersenne.org physically located on Entropia's servers? I still have been unable to get to mersenne.org at all, but was able to get to Entropia's home page (although it took several minutes to partially download before I gave up waiting). Regards, Steve Harris _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Like missing baby's first step
This is indeed a good reason for doing it that way. A similar situation arises when setting up a new client. One time I set one up on a machine without a permanent connection; it was assigned an LL test that would take about a month and immediately started P-1 factoring. A few days later I checked on it and it had found a factor and was sitting there with nothing to do! Now I always make sure a new setup has at least two eponents queued up. Even a machine with a permanent connection will be unable to request new work if the server is down. Steve Harris -Original Message- From: Hoogendoorn, Sander [EMAIL PROTECTED] To: [EMAIL PROTECTED] [EMAIL PROTECTED] Date: Tuesday, July 31, 2001 11:52 AM Subject: RE: Mersenne: Like missing baby's first step This is done to make sure your computer has always some work queued up in case a factor is found and your computer is not online or the primenet server is unavailable. In this situation there is more time to get a new exponent after the factor is found. Sander _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: scientific american
Yes the article does go into great detail re Beowulf clusters, but the penultimate paragraph contains: An equally important trend is the development of networks of PCs that contribute their processing power to a collective task. An example is SETI@home, ... As usual, we get ignored while SETI gets all the publicity. -Original Message- From: xqrpa [EMAIL PROTECTED] To: [EMAIL PROTECTED] [EMAIL PROTECTED]; [EMAIL PROTECTED] [EMAIL PROTECTED] Date: Sunday, July 22, 2001 2:43 AM Subject: Re: Mersenne: scientific american Article seems to detail tightly-coupled Beowulf clusters, not the sort of internet-linked distributed computing we are doing. Have I got the wrong article? I'm looking at: http://sciam.com/2001/0801issue/0801hargrove.html Best Wishes, Stefanovic - Original Message - From: Spike Jones [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, July 21, 2001 10:22 PM Subject: Mersenne: scientific american There is an article this in the new Scientific American on distributed computing, but no mention of GIMPS. I feel cheated. spike _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: scientific american
Most people just find aliens more interesting than primes. One doesn't find articles about prime numbers in the tabloids. I didn't join GIMPS for the cash prizes; I'd have a better chance buying a lottery ticket. But I'm sure many people do join for that reason, probably the same ones who do buy lottery tickets. And if I do happen to find a mersenne prime, the article will appear in places like Scientific American, not the National Enquirer... ;~) Steve -Original Message- From: Nathan Russell [EMAIL PROTECTED] Date: Sunday, July 22, 2001 12:06 PM I think the reason SETI attracts so much of the public attention is simply that anyone can imagine the significance of playing a role in discovering aliens, while the cash prizes for GIMPS (while larger than those for distributed.net) aren't something that really attracts people's attention at first glance. Nathan _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Re: Prime web site
I've noticed that as well... haven't been able to get to the website, but Prime95 has no trouble reporting in or getting exponents. Steve -Original Message- From: Rick Pali [EMAIL PROTECTED] From: Steinar H. Gunderson Both WWW and FTP down from here. :-( Prime95 has no trouble, so that's cool! Rick. _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Spacing between mersenne primes
Random distribution of Mersenne primes does indeed mean we may not find another one for years, but it also means we may find the next two just a few weeks apart. There is also a nearly random order in which the first-time LL tests are _completed_. Assignments are being given out around exponent 12.8 million, but there are 9737 uncompleted in the 11-12 million range and 3496 in the 10-11 million range, as well as over a thousand below that... not to mention the handful below M(39?). We could easily be unlucky enough to have 'skipped over' one already, in which case it could be reported in any day now. (And don't forget... one could have been found recently that hasn't been published yet!) Steve Harris -Original Message- From: Brian J. Beesley [EMAIL PROTECTED] Date: Thursday, May 17, 2001 4:35 PM snip Maybe M39(?) is not massively overdue, but I think it is at least about due now. However, random distribution means we could be unlucky not find another prime for two more years, or possibly even longer... A new discovery would give the project a shot in the arm, though! Regards Brian Beesley _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
