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
Overriding assigned exponent type (was Re: Mersenne: Re: 26 exponents)
Hi all, some thoughts on reaching milestones earlier: Assigned Exponents Report 18 May 2001 10:00 total 52819 to automatically generated User ID like S012345 [1] 10621 = 20% to automatically generated Computer ID like C01234ABCD [2] 17870 = 33% both User ID and Computer ID like S012345 C01234ABCD [3] 8040 = 15% Cleared Exponents Report 18 May 2001 10:00 total 51788 by automatically generated User ID like S012345 [1] 6007 = 11% by automatically generated Computer ID like C01234ABCD [2] 7034 = 13% by User ID and Computer ID like S012345 C01234ABCD [3] 2746 = 5% conclusion and proposal: if the user didn't take the time to fill in his userID/ maschine ID, the chance, that he/she will not finish that assignement is about 2-3 times higher then for other users, as its reasonable to assume, that the _average_ S012345 C01234ABCD user has roughly the same hardware as the _average_ jonmiller dads PIII user. and - probably all hardware geeks, that just want to have a quick check of there maschine, will mostl likely be S012345 C01234ABCD users, as they don't care about primenet. proposal: don't give out DC assignements below 500, if user/maschine is Sd C. don't give out LL assignements below 1000, if user/maschine is Sd C. if the user wants lowest possible assigements, he must enter at least one small 'x' in the ID. that's not very elitarian and very easy on the server side to implement regards tom ehlert [1] C:grep S[0-9][0-9][0-9][0-9][0-9] results.txt rsx.txt [2] C:grep :.*C[0-9A-F][0-9A-F][0-9A-F][0-9A-F][0-9A-F] [0-9A-F][0-9A-F][0-9A-F] results.txt rcx.txt [3] C:grep S[0-9][0-9][0-9][0-9][0-9].*C[0-9A-F][0-9A-F] [0-9A-F][0-9A-F][0-9A-F][0-9A-F][0-9A-F] [0-9A-F] results.txt rsxcx.txt _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Overriding assigned exponent type (was Re: Mersenne: Re: 26 exponents)
I might have added: assigned to User ID and Computer ID like . C01234ABCD 5322 = 10% cleared by by User ID and Computer ID like . C01234ABCD 165 = 0.3% assignments, that are next to be reassigned (timetogo -50 days) all 1549 S12345 471 = 30% C1234ABCD 904 = 58% Sxx Cxx 412 = 26% . Cxx 368 = 23% so, the . C maschines are very uinproductive, too tom _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: Different results
Hello, 1) When testing a new Pc, I obtain two different results from the old and the new one M9357637 is not prime. Res64: BCB1164E6826255E. WW1: C4F561C3,5448242, M9357637 is not prime. Res64: BCB1164E6826255E. WW1: C4F261C3,5448242,0003 Are this results compatible ? 2) I often restart my new PC (for installation purpose of windows 98 se ...). It seems Prime95 is beginning the calculus two early (?) and produce ILLEGAL SUMOUT ERROR. Instead of waiting five minutes, I can stop prime (test/stop menu) then continue (test/ continue menu). Theire are no more errors after that. Is there any way to delay prime95 starting calculus by one minute at boot time ? Best regards, Denis Cazor _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Different results
On Fri, 18 May 2001 15:49:06 +-200, Denis Cazor [EMAIL PROTECTED] wrote: Hello, 1) When testing a new Pc, I obtain two different results from the old and the new one M9357637 is not prime. Res64: BCB1164E6826255E. WW1: C4F561C3,5448242, M9357637 is not prime. Res64: BCB1164E6826255E. WW1: C4F261C3,5448242,0003 Are this results compatible ? This issue, at least, I can deal with. The two results are the same, but as it happens, in order to reduce the chance of a fatal code bug, Prime95 'shifts' the initial inputs into its calculations by a certain amount; that is why the last number in each result is different. As another suggestion, you might want to use the Options - Self-Test option for testing new machines; this option uses pre-computed results, and so you will not need to check the same number twice (a rather time-consuming process); additionally, that option tests Prime95's ability to test numbers of all sizes. Regards, Nathan Russell _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Different results
1) When testing a new Pc, I obtain two different results from the old and the new one M9357637 is not prime. Res64: BCB1164E6826255E. WW1: C4F561C3,5448242, M9357637 is not prime. Res64: BCB1164E6826255E. WW1: C4F261C3,5448242,0003 Are this results compatible ? 2) I often restart my new PC (for installation purpose of windows 98 se ...). It seems Prime95 is beginning the calculus two early (?) and produce ILLEGAL SUMOUT ERROR. Instead of waiting five minutes, I can stop prime (test/stop menu) then continue (test/ continue menu). Theire are no more errors after that. Is there any way to delay prime95 starting calculus by one minute at boot time ? Yup, it's the same. The Res64 is what's important there... it's the residue left over after the final iteration (just the last 64 bits worth anyway...) The WW1 is part of Scott's security check, just to make sure it's not been falsely generated or some such. I assume part of it is related to the date, time, or some other such thing which is why there's one part that's different? If you want to delay Prime95 starting up... hmm...not sure why you'd want to do that, but... Perhaps instead of having it run as a service, you could just put it in your startup group so it doesn't run until you logon. Or, make a batch file and use the SLEEP.EXE program (well, I know it comes with the NT Resource Kit, and there's something similar for Win9x as well) that'll wait for 60 seconds and then launch prime95. That can be setup in the runservices key so it starts when the system boots. Aaron _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: Re: Different results
On Fri, May 18, 2001 at 07:47:10AM -0700, Aaron Blosser wrote: The WW1 is part of Scott's security check, just to make sure it's not been falsely generated or some such. I assume part of it is related to the date, time, or some other such thing which is why there's one part that's different? Wouldn't the last part be the shift count? /* Steinar */ -- Homepage: http://members.xoom.com/sneeze/ _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Different results
At 03:49 PM 5/18/01 +, you wrote: 1) When testing a new Pc, I obtain two different results from the old and the new one M9357637 is not prime. Res64: BCB1164E6826255E. WW1: C4F561C3,5448242, M9357637 is not prime. Res64: BCB1164E6826255E. WW1: C4F261C3,5448242,0003 The RESIDUES matched above -- the result of the TEST is the same. The last sections, and 0003, are not part of the result of the test, but contains other information to help George and Scott know more about the platform, equipment, and version of the software used to perform the test. _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Re: Different results
On Fri, May 18, 2001 at 07:47:10AM -0700, Aaron Blosser wrote: The WW1 is part of Scott's security check, just to make sure it's not been falsely generated or some such. I assume part of it is related to the date, time, or some other such thing which is why there's one part that's different? Wouldn't the last part be the shift count? Um, could be. :) Let's face it, I'm not 100% sure what the last part is there. I know there's the security check, but I dunno what the other stuff is. You're probably right. :) _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
RE: Mersenne: Different results
Hello, 1) When testing a new Pc, I obtain two different results from the old and the new one M9357637 is not prime. Res64: BCB1164E6826255E. WW1: C4F561C3,5448242, M9357637 is not prime. Res64: BCB1164E6826255E. WW1: C4F261C3,5448242,0003 Are this results compatible ? The 64 bits residue's are the same. The WW1 is the version number to see which version of prime95 ran the test. C4F261C3 is a checksum generated by the program to make sure the result is really produced by the programm. Don't know what 5448242 stands for, but the last part is an error counter so the second one has had 3 errors. Sander _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Different results
On Fri, 18 May 2001 10:38:49 -0400, I wrote: This issue, at least, I can deal with. The two results are the same, but as it happens, in order to reduce the chance of a fatal code bug, Prime95 'shifts' the initial inputs into its calculations by a certain amount; that is why the last number in each result is different. Several list members have pointed out that I was in error here; the value that was different is either the error counter or contains information about the platform being used. It looks to me like it might be the error counter; in this case, three errors occured in one run (I'm not sure which type of error). This might be reason to run a fairly lengthy self-test on the machine. Nathan _ 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
On Wed, May 16, 2001 at 07:52:48PM -0500, Ken Kriesel wrote: At 10:56 AM 5/16/2001 -, Brian J. Beesley [EMAIL PROTECTED] wrote: Another point - we're coming up to the second anniversary of the discovery of M38(?) - I think we're overdue to find another one! It would be nice to find another soon. But I don't think we're overdue. Long ago in Internet time I wrote: Recently I've been thinking about this subject, and I've thought what if it starts to work like a fractal, the more distance that you get between points the greater chance there is of a point popping up right in the middle. I'm not a mathamatician by any stretch of the imagination, but I think it's an interesting theory. -- Cheers Steve email mailto:[EMAIL PROTECTED] %HAV-A-NICEDAY Error not enough coffee 0 pps. web http://www.zeropps.uklinux.net/ or http://start.at/zero-pps 2:07pm up 105 days, 14:55, 2 users, load average: 1.14, 1.19, 1.13 _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Different results
Hi all, At 03:49 PM 5/18/2001 +, Denis Cazor wrote: 1) When testing a new Pc, I obtain two different results from the old and the new one M9357637 is not prime. Res64: BCB1164E6826255E. WW1: C4F561C3,5448242, M9357637 is not prime. Res64: BCB1164E6826255E. WW1: C4F261C3,5448242,0003 Are this results compatible ? Sigh, the rarely read readme.txt file says: M1992031 is not prime. Res64: 6549369F4962ADE0. WV1: B253EF24,1414032, This means 2^1992031-1 is not prime - a Lucas-Lehmer test says so. The last 64 bits of the last number in the Lucas-Lehmer sequence is 6549369F4962ADE0. At some future date, another person will verify this 64-bit result by rerunning the Lucas-Lehmer test. WV1 is the program version number. B253EF24 is a checksum to guard against email transmission errors. 1414032 can be ignored it is used as part of the double-checking process. The final value is a set of 4 counters. These count the number of errors that occurred during the Lucas-Lehmer test. To elaborate, the 5448242 in your run is the shift count. Since your 2 runs had an identical shift count, you undoubtedly started the second test using a save file produced somewhere during the first test. An exponent will not be considered double-checked unless the two runs have different shift counts. The 0003 shows that you had 3 ILLEGAL SUMOUT errors on one machine and no errors on the other. The four counters - one byte each - are: count of reproducible errors, count of illegal sumouts, count of roundoff 0.40, count of sum(inputs) != sum(outputs). 2) It seems Prime95 is beginning the calculus two early (?) and produce ILLEGAL SUMOUT ERROR. Instead of waiting five minutes, I can stop prime (test/stop menu) then continue (test/ continue menu). Theire are no more errors after that. This suggestion is actually a high priority for the next release. The error is probably caused by some driver or program initialization that isn't saving the FPU state properly. The error is benign as you found out. I think the main advantage of this feature is it will lead to slightly faster boot times and thereby improve prime95's reputation of not interfering with your everyday work. Regards, George _ 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
Hi, At 02:44 PM 5/18/2001 +0100, Steve wrote: Another point - we're coming up to the second anniversary of the discovery of M38(?) - I think we're overdue to find another one! It would be nice to find another soon. But I don't think we're overdue. The Sept 30, 1999 status.htm page showed 3.12 expected new Mersenne primes to be found below 20.4M. The latest status.htm page shows 1.49. So during that time we found zero primes instead of the expected 1.63 primes. By no means unusual, but it is unlucky. Another way to look at it. Roughly speaking supercomputers owned the region below 1.3M, GIMPS above that. We've roughly tested three doublings 1.3M to 2.6M, 2.6M to 5.2M, 5.2M to 10.4M. There are 1.78 an expected Mersenne primes per doubling. GIMPS should have found 5.34 primes. Oh well, maybe the 10.4M to 20.8M doubling will be especially rich in new Mersenne primes :) Regards, George _ 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
On Fri, 18 May 2001 14:47:49 -0400, George Woltman wrote: Another way to look at it. Roughly speaking supercomputers owned the region below 1.3M, GIMPS above that. We've roughly tested three doublings 1.3M to 2.6M, 2.6M to 5.2M, 5.2M to 10.4M. There are 1.78 an expected Mersenne primes per doubling. GIMPS should have found 5.34 primes. Another way to look at it is that we were unlucky with two doublings, and slightly lucky with one. Note that the M#35/M#36 split is, while nowhere near the widest known, unusually wide, so we were unlucky there too. These things, of course, are totally unpredictable - there is one precedent for adjacent exponents (M127 and M521) having a ratio of 4.102, which means it wouldn't be a record even if we found no new primes through the ~25M range. Here's hoping that isn't the case! Nathan _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: Apple vs. GIMPS
I'm contemplating getting a Apple, probably an IMac. I think I've seen Gimps for the Apple, am I right? How well does an Apple running Gimps compare to a Pentium/Win* combination? Of sourse Gimps wouldn't be the only thing I run but I would like to run it on any pc I have access to. Cheers... Russ _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
