Mersenne Digest Saturday, 6 March 1999 Volume 01 : Number 521 ---------------------------------------------------------------------- From: "Brian J Beesley" <[EMAIL PROTECTED]> Date: Thu, 4 Mar 1999 09:19:45 GMT Subject: RE: Mersenne: Re: Mersennes for Martians Yesterday I wrote: > [... snip ...] I believe the > Chudnovskys (apologies if I've misspelled their name) had > dedicated hardware that could do a 2^20 bit by 2^20 bit > multiplication in less than a microsecond, about 15 years ago. > (Reference, "The Joy of Pi") Oops. When I went to check this reference (which I knew was in something I'd read recently) I found it wasn't in "The Joy of Pi". However, I found in Knuth vol 2 (3rd ed) p311 reference to "Little Fermat", a general-purpose computer built by the Chudnovskys in 1985 which could multiply 2 million-bit integers in less than 0.1 sec. I'm a lot less impressed - most of those of us running mprime, Prime95 etc. will be doinf rather better than this on cheap commercial PCs at the moment! Sorry for the misinformation Regards Brian Beesley ________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm ------------------------------ From: David L Nicol <[EMAIL PROTECTED]> Date: Thu, 04 Mar 1999 12:21:23 -0600 Subject: Mersenne: better way to strip trailing whitespace from a file perl -pe 's/\s+\Z//' <prime3.txt ________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm ------------------------------ From: David L Nicol <[EMAIL PROTECTED]> Date: Thu, 04 Mar 1999 12:54:07 -0600 Subject: Mersenne: M37 as six page postscript document is in the directory http://www.tipjar.com/mersenne/ Formatting thanks to a2ps ________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm ------------------------------ From: Wojciech Florek <[EMAIL PROTECTED]> Date: Thu, 4 Mar 1999 23:32:37 +0100 (MET) Subject: Mersenne: Diagrams once again Hi! Since some of you have showed interest in `my' diagrams I've worked a bit of them. Now I use bars and a *.txt file with data is available. Please remember that diagrams count only the Prime Net accounts listed in Top Producers Awards List (no GIMPS results, no manual results). I don't know which accounts are active and which are not. Accounts are not grouped into GIMPS1, GIMPS2, GIMPS as was proposed here. Maybe it will be worth doing such split? To Paul D. (and other which were surprised (?) that I had changed 0.00 to 0.01): 1. I don't want to omit any account 2. I use log scale, so the values have to be positive 3. this entry in the Top Prod list reads 5747. xxxxxxxxx 0.000 0 0.003 0 0.00 He/she made 0.003 CPU years of factorization long time ago (or it took a lot of time for him/her). So 0.003*365*24/days till today is less than 0.00499.... (rounded to 0.00). Try http://main.amu.edu.pl/~florek/990304.gif Wojciech Florek (WF) Adam Mickiewicz University, Institute of Physics ul. Umultowska 85, 61-614 Poznan, Poland phone: (++48-61) 8273033 fax: (++48-61) 8257758 email: [EMAIL PROTECTED] www: http://main.amu.edu.pl/~florek ________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm ------------------------------ From: "Alan Vidmar" <[EMAIL PROTECTED]> Date: Thu, 4 Mar 1999 15:53:41 -0700 Subject: Mersenne: Will the next version of the Prime95 client take advantage of the PIII's SSE extensions? Hi All, George, Will the next version of the Prime95 client take advantage of Intel PIII's SSE extensions? Thanks, Alan "A programmer is a person who turns coffee into software." Alan R. Vidmar IT Professional III [EMAIL PROTECTED] University of Colorado *** This message printed with 100% recycled electrons *** ________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm ------------------------------ From: Ken Kriesel <[EMAIL PROTECTED]> Date: Fri, 05 Mar 1999 00:46:37 -0600 Subject: Mersenne: Re: Mhz At 08:55 AM 1999/03/03 -0600, Ryan McGarry <[EMAIL PROTECTED]> wrote: >Actually, the 8088 ran at slightly over 8 MHz. The 8086, an earlier >version, ran at 4.77. An 8088 was my first computer... Ah. Memories. > >Ryan McGarry Actually, the IBM PC ran at 1/3 of 14.31818 Mhz, approximately 4.773Mhz. That crystal frequency was selected because it could be divided by 4 on the Color Graphics Adapter (CGA) to provide the TV color burst frequency 3.58Mhz and by 3 to be under 5Mhz, because IBM used 5Mhz-rated 8088 chips. The clock was further divided for several other functions, including serial port rates, system timers, etc. I owned an original IBM PC (64KB motherboard) for 15 years, and studied the clock circuitry well enough early on to split the clocks and hop the cpu up to 7.6 Mhz while leaving the 14.31818Mhz bus line & serial ports etc unaffected, after selectively desoldering a few 74xxx chips from the motherboard and replacing them with socketed 74ALSxxx equivalents and getting an 8Mhz NEC V20, while still using the 250ns soldered-in DRAM. There were multiple speed grades for each processor. The 8086 reached 10Mhz. The 80286 had grades from 4 to 16Mhz or higher; the 386 from 12.5 to 40Mhz; the 486 from 25 to 133, and the Pentium from 60 to 233. (Not all from Intel, and perhaps I have missed a speed grade here and there.) >1977: 1Mhz 6502 or 4Mhz Z80 (also the Vax 11/780; Mhz?) >1981: 4.77Mhz 8088 in the IBM PC >1984: 6Mhz in the IBM AT (and later, IBM released other models of the AT including an 8Mhz clock) Ken ________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm ------------------------------ From: Ken Kriesel <[EMAIL PROTECTED]> Date: Fri, 05 Mar 1999 01:10:33 -0600 Subject: Re: Mersenne: Double-checking (was Chronons) At 10:01 AM 1999/03/02 -0500, Paul Derbyshire <[EMAIL PROTECTED]> wrote: >At 02:01 PM 2/28/99 -0500, you wrote: >>Finding an error in the first LL test is not rare. I've said about 1 in >>200 are incorrect. > >Yeah, but most of those are "silent mutations" in nonzero residues, not >errors in the purported primality result, right? Right. The odds heavily favor both mismatched residues being nonzero. A zero residue at the last iteration is what indicates primality. >Also what causes the errors, bugs in the code? What I've seen most often is that prime95 and its relatives provide early warning of unreliable hardware, whether cpu, RAM module, or motherboard. >Is work being done on >finding subtle errors in the software? Yes, in the sense that for the first two+ years, double checking was done only on a different program on a different processor architecture than the original check, and currently some double checks do so still. Either programming errors or chip design errors would surface in that scenario. I've volunteered to run on Intel, one or two exponents in each run length to try out the code before the bulk of the GIMPS effort is routinely being assigned exponents in the higher run lengths. Perhaps someone running a different architecture would be willing to double check them. George has made provisions both to detect some errors and to prevent those from causing the loss of all work up to that point on the exponent. For example: Iteration: 3743629/5070277, ERROR: SUM(INPUTS) != SUM(OUTPUTS), 5.26887446743531e+016 != 1.990777258736701e+016 Possible hardware failure, consult the readme file. Continuing from last save file. means an error has occurred and been detected, and to save the last few weeks' work, the last half hours' is discarded and tried again. >Are some of them, in the case of >Prime95, caused by Winblows? Iteration: 1407235/5070277, ERROR: ILLEGAL SUMOUT Possible hardware failure, consult the readme file. Continuing from last save file. Possibly these are software, according to George's readme.txt, under the section Possible Hardware Failure If it is software, it is not necessarily the fault of Windows or Microsoft. Could be a bum driver not doing things it should. >(IOW, are there more errors per P90 CPU hour >among Winblows boxes than among mprime boxes?) > >I figure only a small percentage of participants have actual faulty >hardware, and that spurious cosmic ray bit flips are caught by checksumming >of some kind. (Is that what ILLEGAL SUMOUT is, a checksum mismatch?) ________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm ------------------------------ From: "Brian J Beesley" <[EMAIL PROTECTED]> Date: Fri, 5 Mar 1999 11:59:12 GMT Subject: Re: Mersenne: Double-checking (was Chronons) > >Yeah, but most of those are "silent mutations" in nonzero residues, not > >errors in the purported primality result, right? > > Right. The odds heavily favor both mismatched residues being nonzero. > A zero residue at the last iteration is what indicates primality. Depends on what you mean. If a Mersenne number that has been tested once really is prime, but the test "went wrong", then we have a wrong result i.e. calling the number composite when it isn't. This is why double-checking is so important, if we want to find *all* the Mersenne primes for exponents up to a given limit. There *might* be one or two lurking somewhere in the mass of exponents which have only been tested once. > > >Also what causes the errors, bugs in the code? > > What I've seen most often is that prime95 and its relatives provide > early warning of unreliable hardware, whether cpu, RAM module, or motherboard. Usually caused by overheating - failed CPU fan, poor ventilation or excessively hot environment, overclocking, poor thermal contact between processor substrate and heatsink ... > > >Is work being done on > >finding subtle errors in the software? > [... snip ...] > I've volunteered to run on Intel, one or two exponents in each run length > to try out the code before the bulk of the GIMPS effort is routinely being > assigned exponents in the higher run lengths. Perhaps someone running a > different architecture would be willing to double check them. Ken, could you tell me which exponents you've run, which require checking, & I'll double-check using MacLucasUNIX on a 533 MHz Alpha system (approx. same speed as PII-300 running Prime95) I would have thought one exponent per run length would be enough, provided our results agree. My Alpha system has ECC memory etc. so should be reasonably reliable. [... snip ...] > >Are some of them, in the case of > >Prime95, caused by Winblows? > > Iteration: 1407235/5070277, ERROR: ILLEGAL SUMOUT > Possible hardware failure, consult the readme file. > Continuing from last save file. > > Possibly these are software, according to George's readme.txt, under the > section Possible Hardware Failure > If it is software, it is not necessarily the fault of Windows or Microsoft. > Could be a bum driver not doing things it should. There's a distinct *possibility* that *any* software running under Win 9x could directly alter values in Prime95's workspace, since Win 9x applications have access to the whole physical address space. In Win NT (and linux), only kernel mode tasks can do this, so the likelihood of memory being clobbered by a rogue application is a great deal less. > > >(IOW, are there more errors per P90 CPU hour > >among Winblows boxes than among mprime boxes?) Don't know. It may be possible to get this info from George's database, but it would take a fair bit of digging out. > >I figure only a small percentage of participants have actual faulty > >hardware, and that spurious cosmic ray bit flips are caught by checksumming > >of some kind. I think you'll find it's surprising how many systems become a great deal more reliable if (a) the PSU is adjusted so that the supply rails are accurate (+/- 5% errors are common), (b) the cooling is improved (even turning down the room thermostat by a couple of degrees can make a difference), (c) the system is clocked just a few percent slower (especially if it has been overclocked to start with). Lots of users put up with flaky hardware; they get used to Windoze locking up once in a while & just blame Bill Gates. He's not *always* the guilty party. Also, in my fairly extensive experience, systems that have been well-handled from a electrostatic point of view tend to be reliable, whereas those where people have changed memory etc. without observing anti-static precautions tend to be flaky. Regards Brian Beesley ________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm ------------------------------ From: "James Smith" <[EMAIL PROTECTED]> Date: Fri, 5 Mar 1999 12:51:47 -0000 Subject: Re: Mersenne: M37 as six page postscript document I had a look at this, and found it a little hard to read, so if anyone cares I have duplicated it, along with a couple of other file formats, to the following location. ftp://ftp.xsite.ltd.uk/pub/prime/ - -- James Smith [EMAIL PROTECTED] >is in the directory >http://www.tipjar.com/mersenne/ > >Formatting thanks to a2ps ________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm ------------------------------ From: "Tim Charron" <[EMAIL PROTECTED]> Date: Fri, 5 Mar 1999 07:54:07 -0500 Subject: Re: Mersenne: M37 as six page postscript document > is in the directory > http://www.tipjar.com/mersenne/ I just recently did a do-it-yourself hardware modification to the memory module of my Palm III. It now has 4 Megs of memory (double what is available from the manufacturer). As a lark (and because I now can!), I put M37 in it. If anyone else wants it, get it at http://www.interlog.com/~tcharron/Mersenne(3021377).PDB - -- Tim Tim Charron [EMAIL PROTECTED] [EMAIL PROTECTED] ________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm ------------------------------ From: George Woltman <[EMAIL PROTECTED]> Date: Fri, 05 Mar 1999 15:05:29 -0500 Subject: Re: Mersenne: Double-checking (was Chronons) Hi, At 11:33 PM 3/2/99 +0000, Tony Forbes wrote: >George Woltman <[EMAIL PROTECTED]> writes >>Finding an error in the first LL test is not rare. I've said about 1 in >>200 are incorrect. When the entire 1,400,000 - 2,000,000 range has >>been double-checked I'll perform some more rigorous analysis of the >>reliability of first-time LL results. > >This is slightly worrying. A prelimiary analysis for your consumption: Looking at prime95 and mprime results between 1,400,000 and 2,000,000: There are 220 residues that have been proven wrong. These were produced by 99 different users. 78 of these results were produced by version 17. Of these 78, 53 did not report any errors, 3 reported illegal sumout errors, and 22 reported the more serious roundoff and mismatched sum errors. There are 27490 verified results. 12665 of these were produced by version 17. Of these 12665, 12493 did not report any errors, 120 reported illegal sumout errors, and 53 reported the more serious errors. There are 2204 unverified results on 1909 exponents. This does not mean that there are 295 more bad results. It is not uncommon to have 2 or 3 prime95 results but the exponent is not considered verified because one of the results must be from version 17. So what does the above mean? Feel free to draw your own conclusions and post them to the list. I think the error rate is somewhere between 78 in 12665 for version 17 and 142 in 14825 for pre-v17 results. Actually, the error rate will be higher because of the pending triple-checks in the unverified results. It looks like my estimate of 1 in 200 was too optimistic. It also looks like the illegal sumout errors do not seriously impact reliability, but the other errors mean you have only a 70% chance of producing a good result. >The number of CPU cycles for performing the >LL-test for exponent n is approximately proportional to n^2*log(n). >Assuming, maybe rather naively, that the risk of computer error is >proportional to the number of CPU cycles, I personally think this is too naive an assumption. I think a PC is either good at producing accurate results or it isn't. Obviously, the longer the test, the more likely an error will creep in - but my gut tells me this is a relatively minor effect. >Do we have any statistics for the larger exponents? No. There have been a few scattered double-checks, but nothing statistically significant. Best regards, George ________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm ------------------------------ From: Leo Feret <[EMAIL PROTECTED]> Date: Fri, 05 Mar 1999 18:49:27 -0500 Subject: Re: Mersenne: M37 as six page postscript document Thanks very much for your efforts. "Pi" the way, the sequence 314159 happens to be part of the Great Number. Leo Feret James Smith wrote: > I had a look at this, and found it a little hard to read, so if anyone cares > I have duplicated it, along with a couple of other file formats, to the > following location. > > ftp://ftp.xsite.ltd.uk/pub/prime/ > > -- > James Smith > [EMAIL PROTECTED] > > >is in the directory > >http://www.tipjar.com/mersenne/ > > > >Formatting thanks to a2ps > > ________________________________________________________________ > Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm ________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm ------------------------------ From: Gordon Spence <[EMAIL PROTECTED]> Date: Sat, 06 Mar 1999 15:22:52 +0000 Subject: Mersenne: Errors in previous results There has been speculation on the list recently about the chances of finding previous errors and the implications for various things. I have recently retested M2018167 and found a factor that was previously missed. So what?, that surely is the whole point of double checking. This number will now be tested a third time to dtermine which of these two results is correct. As long as we do the rigorous double and triple checking then why should we be worried? regards G Gordon Spence, Nokia IP Telephony Applications Engineer Grove House, Waltham Way, [EMAIL PROTECTED] White Waltham, Maidenhead, http://www.nokiaiptel.com/ Berkshire, SL6 3TN, UK. ________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm ------------------------------ From: Greg Hewgill <[EMAIL PROTECTED]> Date: Sat, 6 Mar 1999 00:56:17 -0800 Subject: Re: Mersenne: M37 as six page postscript document On Fri, Mar 05, 1999 at 06:49:27PM -0500, Leo Feret wrote: > Thanks very much for your efforts. "Pi" the way, the sequence 314159 happens > to be part of the Great Number. The probability of an N-digit number appearing somewhere in a random sequence of 10^N digits is approximately 1 - (1/e), or about 0.632. The probability of an N-digit number appearing at a specific position is 1/(10^N). So the probability of it not appearing in any position is (1 - 1/(10^N))^(10^N). As N increases, this converges very quickly to 1/e. Greg Hewgill ________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm ------------------------------ From: "Robert G. Wilson v, PhD ATP" <[EMAIL PROTECTED]> Date: Sat, 06 Mar 1999 18:39:58 -0600 Subject: Re: Mersenne: mersennes for exocivilizations All you have to do is look it up in Neil J.A. Sloane's "The Encyclopedia of Integer Sequences," Academic Press, 1995. Or better yet, look it up online at http://akpublic.research.att.com:80/~njas/sequences/ . Bob. Spike Jones wrote: > [EMAIL PROTECTED] wrote: > > > Then ask them how many Mersenne primes they know. Then send them a > couple, and > > they can send us a couple, so forth. It could be a race. Can we find > the 137th > > Mersenne prime before the Aeraibvcas do? Our superiority as a race is > at stake! > > Let me turn this around. When or if we ever receive signals from > exocivilizations, those signals might well be in the form of a list of > primes, as in Sagan's excellent book and now movie Contact. > It would not surprise me at all if instead of a list of primes, they > send us the series 2,3,5,7,13,19,31,61,89,107,127,521... > > If they did, most scientists would be baffled, but you and I would get > it. We > would grok that message bigtime. We would be among the approximately > 50,000 humans of 6E9 that would grok that message immediately without > having to look it up. spike > > ________________________________________________________________ > Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm ________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm ------------------------------ From: "Robert G. Wilson v, PhD ATP" <[EMAIL PROTECTED]> Date: Sat, 06 Mar 1999 19:42:40 -0600 Subject: Re: Mersenne: mersennes for exocivilizations Ken Kriesel wrote: > > Stating the exponents rather than the base10 representation seems to > me to be almost the ultimate in data compression. (2^521-1 has 157 digits; > the advantage increases along with the exponent, uh, exponentially.) > 2^p -1 is prime for the following ps: 2, 3, 5, 7, 13, 17, 19, 31, 61, 89, 107, 127, 521, 607, 1279, 2203, ..., 1257787, 2976221, 3021377, ... . But all of these are primes. Two is the first prime, denoted as p(1), three is p(2), five is p(3), etc. So therefore the best data compression is represent the Mersenne primes is to denote the n, such that 2^p(n) -1 is prime for the following ns: 1, 2, 3, 4, 6, 7, 8, 11, 18, 24, 28, 31, 98, 111, 207, 328, 339, 455, 583, 602, 1196, 1226, 1357, 2254, 2435, 2591, 4624, 8384, 10489, 12331, 19292, 60745, 68301, 97017, 106991, 215208, 218239, ... , . ________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm ------------------------------ From: [EMAIL PROTECTED] Date: Sat, 6 Mar 1999 22:46:09 EST Subject: Re: Mersenne: mersennes for exocivilizations In a message dated 3/6/99 9:22:49 PM Eastern Standard Time, [EMAIL PROTECTED] writes: > 1, 2, 3, 4, 6, 7, 8, 11, 18, 24, 28, 31, 98, 111, 207, 328, 339, 455, 583, > 602, > 1196, 1226, 1357, 2254, 2435, 2591, 4624, 8384, 10489, 12331, 19292, 60745, > 68301, 97017, 106991, 215208, 218239, ... , . > Okay, now what if we get a sequence like this: 5, 9, 10, 12, 13, 14, 15, 16, 17, 19, 20, 21, 22, 23, 25, 26, 27, 29, 30, 32, ...., 97, 99, 100, ... ________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm ------------------------------ From: Spike Jones <[EMAIL PROTECTED]> Date: Sat, 06 Mar 1999 20:21:57 -0800 Subject: Mersenne: mersennes for our civilization Robert G. Wilson v, PhD ATP wrote: > All you have to do is look it up in Neil J.A. Sloane's "The Encyclopedia of > Integer Sequences," Academic Press, 1995. Or better yet, look it up online > at http://akpublic.research.att.com:80/~njas/sequences/ . Bob. Thanks for the site Dr. Bob! Thats a cool one. Yesterday a coworker saw my six page printout of the Great Number on the wall of my office, asked, and I explained GIMPS and the LL algorithm, how the program checks to see if M(n) divides S(n). He is a clever chap and asked why prime95 starts from scratch calculating S(n) instead of getting it from a previous check: if you calculated S(6000001) and your needed S(6000031) for your next check, for instance, why would you not take the previously calced S(6000001) then square and subtract 2 thirty times. I pointed at the Great Number and said: Because S(3021377) has this many bits. Knock off a dozen digits, and it would take that many years just to send the data from one computer to another. I felt pretty smart. Then he asked: if S(n) has so many bits, how does a desktop computer handle it? Me: duuuuuuuh. I dont know. {8-[ Do you know? Can someone explain it to me in words an ordinary person would understand, how the Prime95 LL algorithm works? spike ________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm ------------------------------ End of Mersenne Digest V1 #521 ******************************
