Mersenne: QA testers call
I am looking for about 20-50 additional ambitious very patient QA testers with extremely fast hardware, and some significant free storage space, to participate in runs on selected exponents in the larger fft runlengths. The selected exponents will frequently be fully trial factored, or nearly so. Though many may be prime95 or mprime users, this is not a requirement, and participation of users on nonIntel cpus is encouraged. Participants in this phase of the QA should be willing to coordinate with a partner, running LLtests and double-checks of the same exponent in parallel, and cc George Woltman and myself, interim residues at suitable intervals. Interim files (which can each be sizable) should be preserved until interim residues of a later interim check are known to match. (Ideally all interim files would be kept, at intervals of 1-2 million iterations, until an exponent is completed double checks ok.) Participants should agree to sign on for at least 6 months, preferably much longer, and to transmit the last valid intermediate file or interim file to an ftp server if quitting, or when necessary for debugging. (Note, the upper end, 79,300,000, takes an estimated 6.5 years on a PentiumII-400, nonstop.) Participants should agree to install version upgrades that may be required from time to time, waiting a day or more to ensure it's a stable version, and migrate the tests in progress to their fastest available hardware as hardware upgrades are made. (It may be possible to get partial cpu-time credit for partially LLtesting an exponent that is then completed by someone else but this is not guaranteed. This could be an extra administrative headache for George Woltman and myself.) In exchange for all this time and trouble, testers will have a reduced chance of finding a prime and a delay in receiving cpu credit (due to the long runtimes), but get a shot at completing primality tests of exponents unlikely to be surpassed for some time. The purposes of this endeavor are: 1) Add to the list of known, checked residues, some entries in currently very sparse or completely empty runlengths (ahead of checkout result return by typical GIMPS Primenet users) for qualification of v19 prime95 its variants, future versions, other software. 2) Verify the long term operation accuracy of prime95 v19 and its relatives (and later versions) in the new longer runlengths. 3) Gain experience with the tandem-running approach. 4) Have fun. Volunteers, please respond by email to me with the following information: Your full name your email address your preferred runlength(s) how many exponents you'd like to take on in each runlength Description of cpus available for QA testing, as in the hypothetical example below, to judge suitability of cpus for various exponents: Name CPU OS RAMavailable (hr/day)/(day/wk) xyzPII-500 WinNT (build 1381 SP5) 128MB 24/7 aAlpha21264-600 TruUnix Vxxx 512MB 15/5 +24/2 5; various Celeron500 Win95 128MB 24/7 omega 4xPIII-600 WinNT 4sp5+hotfixes 256MB 24/7 (CPU descriptions will not be shared among participants or with the mail list.) Ken _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Decamega Tests (was: RE: Mersenne: GIMPS client output)
HI! Anyone tought of send ing these P and Q once a month to the server.. in the case where someone would abandon a quest, it could be continued by someone else ... Notice that in v19 if you set it to get 10 Million range numbers you get a warning about it taking a year on a 500 Mhz P-2, and odds of 1 in 250,000. If the price would be won the split would be according to CPU cyle or CPU time !?!?!?! Philippe BTW for the nice Screen Saver interface I would suggest some fun GFX (something easy to draw) from the residue of each Iteration with a Bar decreasing with the work to do on the exponent I don't know how the software of primenet work but When I wanted a really fast execution I was doing like so (The last time I coded it was in 1991) A=0 "do it" do job on A do job on A do job on A do job on A ... (as many times it's logical depend on size order) do job on A if Avalue go "do it" if Avalue do it backward till it's OK ( if you pass straight ahead oops) JUMP "done" Other of my trick was to do the same unchecked bunch of ADD then till a register create a CPU fault, trap the fault and see were is the registers =) That was removeing all the checking of condition till I had a fault ... saving many little cycles These are just theory Philippe _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne Digest V1 #630
Mersenne Digest Wednesday, September 22 1999 Volume 01 : Number 630 -- Date: Tue, 21 Sep 1999 21:25:02 +0200 From: "Floris Looyesteyn" [EMAIL PROTECTED] Subject: Mersenne: FDIV Pentium error I was wondering if Prime95 is affected by the Pentium FDIV bug. (or some name like that). I ask this because now i'm also using it on my laptop (great work george!) and when i installed linux some time ago it said the processor had this bug. Floris Looyesteyn _ 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 -- Date: Tue, 21 Sep 1999 22:58:59 +0200 From: "Lars Lindley" [EMAIL PROTECTED] Subject: Re: Mersenne: FDIV Pentium error I was wondering if Prime95 is affected by the Pentium FDIV bug. (or some name like that). I ask this because now i'm also using it on my laptop (great work george!) and when i installed linux some time ago it said the processor had this bug. It should not be a problem because Linux recognizes the bug and uses a workaround. Regards /Lars _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers -- Date: Tue, 21 Sep 1999 23:11:46 +0200 From: "Steinar H. Gunderson" [EMAIL PROTECTED] Subject: Mersenne: Re: Re: Timing(?) errors On Tue, Sep 21, 1999 at 02:03:54PM -0500, Willmore, David wrote: Correct, it does not. Normally, though, when you're swapping, proper L2 cache coloring is the least of your performance problems. Yes, but if you _force_ swap-out-swap-in, like ReCache does? /* 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 -- Date: Tue, 21 Sep 1999 23:12:58 +0200 From: "Steinar H. Gunderson" [EMAIL PROTECTED] Subject: Mersenne: Re: FDIV Pentium error On Tue, Sep 21, 1999 at 09:25:02PM +0200, Floris Looyesteyn wrote: I was wondering if Prime95 is affected by the Pentium FDIV bug. (or some name like that). I've run it with on a P60 (with the FDIV bug) for 2-3 years now (at least pre-PrimeNet), and it has never been a problem. Remember that the bug influences FDIV only (which is very slow -- and thus George doesn't use it that much ;-) ), and not to a very great extent either. /* 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 -- Date: Tue, 21 Sep 1999 16:59:20 -0500 From: "Willmore, David" [EMAIL PROTECTED] Subject: RE: Mersenne: Re: Re: Timing(?) errors Random chance. I wouldn't count on it. -Original Message- From: Steinar H. Gunderson [SMTP:[EMAIL PROTECTED]] Sent: Tuesday, September 21, 1999 4:12 PM To: [EMAIL PROTECTED] Subject: Mersenne: Re: Re: Timing(?) errors On Tue, Sep 21, 1999 at 02:03:54PM -0500, Willmore, David wrote: Correct, it does not. Normally, though, when you're swapping, proper L2 cache coloring is the least of your performance problems. Yes, but if you _force_ swap-out-swap-in, like ReCache does? /* 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 _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers -- Date: Tue, 21 Sep 1999 18:07:44 -0400 From: George Woltman [EMAIL PROTECTED] Subject: Re: Mersenne: Interesting PrimeNet Error Hi, At 06:24 PM 9/20/99 -0700, Eric Hahn wrote: Sending text message to server: M10461667 has a factor: 7841028322998353783 Sending expected completion date for M10461667: Sep 21 1998 ERROR 11: Exponent already tested. Yes, the expected completion date message was expected as the machine was still testing (for smaller factors) I just found it interesting that PrimeNet would produce an error like this. What would happen if Prime95 should happen to find a smaller factor? Would it be accepted? This is really a flaw in our original design that we've never bothered to fix. I believe prime95 shouldn't send
Mersenne: Oops again - Version 19 - beta #4
Hi all, Only Linux users are affected. Apparently I suffered floppy confusion or other operator error in rebuilding beta #4 for linux. The corrected beta #4 for linux is now available. The linux beta dynamicly linked with glibc 2.1 is at: ftp://entropia.com/gimps/mprb.tgz The linux beta staticly linked is at: ftp://entropia.com/gimps/sprb.tgz Sorry for the trouble, George _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Front-end design
On Thu, Sep 23, 1999 at 01:53:33PM +0200, Alexander Kruppa wrote: Robert van der Peijl wrote: He further writes: There are some Linux folks that like the present program because it doesn't use X-windows. I certainly do! A program like mprime that is supposed to run in background at all times should not depend on a X server running. Quite. For a start, some of the servers on which I have mprime running don't have an X server. I'm not always logged into them, and X on my desktop machine has been known to be less than fully stable (curse netscape for taking down first X and then the entire machine the other day). Meanwhile mprime can remain running for months without requiring a restart. Maybe the setup could be handled similar to the NT service version, with the actual client running without screen I/O in background, and a GUI program to handle .ini file setting, Status reports, etc. Personally I don't see a need, but I can see that some people might (I saw some 95 boxes the other day running the SETI screensaver, and it does look quite slick). The mprime console program is fine, except that there are now too many options for them to be displayed on a standard 80x24 window or console - perhaps things could be rearranged slightly? Incidentally, can anyone explain why under v19.0.2 I'm getting "ERROR 2250: Server unavailable" messages? Since 18.1.2 as running on another machine has no problems, it's evidently not a case of the server being down. The FAQ mentions a problem on v18 for those using RPC, but I was under the impression I've always been using http... -- Robin Stevens [EMAIL PROTECTED] Merton College, Oxford OX1 4JD, UK http://www-astro.physics.ox.ac.uk/~rejs/ (+44) (0)1865: 726796 (home) 273337 (work) 273390 (fax)Pager: 0839 629682 When puns are outlawed only outlaws will have puns. _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Front-end design
Sorry, I've deleted the mail. QWhere can I get the most recent Prime95 source code from, and what should I compile it with? I'd like to at least try to make a front-end, and I'm sure at least the base of a screen saver would take all of 30 minutes. I know that we'd perfer people to use prime95 all the time, but a screen saver would be useful for people who refuse to... Chris Jefferson, Girton College, Cambridge, [EMAIL PROTECTED] Someone may have beaten me to Fermat's Last Theorem, but I've done Riemann's general equation. However it won't fit in my signature file... _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: Mlucas 2.6/2.7: corrections
Dear All: some corrections to my two postings of yesterday (West Coast U.S. yesterday, at least): The error summary for Mlucas 2.6c should read as follows: 1) Any first exponent at a particular FFT length should be fine; 2) Any subsequent exponent at the same length (whether there are exponents using a different runlength between them or not) will be bad. Some of the Alpha 21064 timings in the Mlucas 2.7 timings table were wrong (they were for 2.6, not 2.7). The corrected table follows - the corrected timings are indicated with a +. I also replaced the tabs with spaces, so hopefully the table will transmit better this time. (If it's misaligned on your end, try switching your browser or edit window to a true type font): Platform/per-iteration time (sec) 200MHz 21064 400MHz 21164 195MHz R10K 250MHz R10K cache sizes 8KB L1 32kB L1 32kB L1 unknown 96KB mixed 512KB L2 4MB L2 1MB L2 FFT length -- -- -- - 64K.095.035 .041 .035 80K.12 .045 .054 .047 96K.16 .057 .069 .062 112K.19 .069 .082 .074 128K.21 .078 .100 .090 160K.27 .098 .118 .115 192K.32 .115 .143 .144 224K.39 .140 .170 .170 256K.48 .177 .221 .210 320K.65 .241 .261 .248 384K.81+.316 .345 .317 448K.98+.399 .388 .354 512K 1.17+.545 .525 .451 640K 1.50+.620 .649 .543 768K 1.82+.756 .814 .659 896K 2.16+.890 .932 .771 1024K 2.42+ 1.20*1.16 .937 1280K 3.201.32 1.40 1.13 1536K 4.151.86 1.90*1.54* 1792K 4.992.13 2.04 1.68 2048K 5.452.73 2.57 2.22 2560K 6.933.16 3.25 2.61 3072K 8.334.02 3.92 3.16 3584K 9.964.53 4.58 3.69 4096K 11.425.62 6.14 7.26* Also, in my comments regarding the anomalous timings (*) in the table yesterday, I had no explanation for the slowish 21164 time at 1024K. It may in fact be that at 1024K FFT length, the small FFT sincos and DWT weights tables (which contain sqrt(n) 64-bit floats each) are each 8KB and thus can't reside completely in the 21164's 8KB L1 cache along with anything else. The MIPS R1 has a 32KB L1 cache, so doesn't suffer the same problem. Thus, the only remaining unexplained anomaly is the truly bizarre behavior on the 250MHz R1 at 4096K. -Ernst _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: whoops
Please note that I mistyped Guillermo Ballester Valor's e-mail address in sending my last posting - it should be [EMAIL PROTECTED] -Ernst _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: Re: FFTW for GIMPS?
Guillermo Ballester Valor writes: Do you Know the GNU-FFTW package ?(The Fastest Fourier Transform in the West). Last week I thought it would be interesting to see if it is as fast as they say. It is really a fast C-written FFT code. Hi, Guillermo (please, let's use first names - I'm an informal guy) - While not having used it myself, certainly I've heard of FFTW. Note that a better person to comment on your questions might be Jason Papadopoulos ([EMAIL PROTECTED]) - he adapted FFTW for his very fast SPARC Fermat number code. My comment is this: If you want to create a fast FFT-based program in a short time, FFTW is certainly a good way to do it. On the other hand, if you're really striving for extreme performance (i.e. trying to write a code that possibly many people will use intensively), it is best to have a code whose details you understand well. In my case, the latter criterion (and the fact that I wanted to learn as much as I could about FFTs) led me to write my own code. I started with the Numerical Recipes FFT (slow and not very accurate, but easy to play with) about 3 years ago and have been working on it ever since - my current code looks nothing like the NR FFT, but you have to start somewhere. Looking at the FFTW timings page, for a length-262144 real-vector transform they list (http://www.fftw.org/benchfft/results/alpha467.html) a performance of around 105 "MFlops" on a 467 MHz Alpha 21164. Using their definition of MFlops for real FFTs, this translates to a per-FFT time of 0.5*[5*262144*log2(262144) Flop]/[115 MFlop/sec] = 0.112 sec. My LL code does 2 FFT's plus other operations per Mersenne-mod squaring, so we estimate about 80% of the per-iteration time equals one FFT. At 256K vector length it needs .177 sec per iteration on a 400 MHz 21164, which leads to an estimate of .40*.177*400/467 = 0.061 sec on a 467MHz 21164 which is significantly faster than FFTW. At real-vector length 362880 (the closest I could find to 384K), FFTW needs 0.5*[5*362880*log2(362880) Flop]/[125 MFlop/sec] = .134 sec per FFT, whereas Mlucas 2.7 (multiplying the 384K = 393216 timing by 362880/393216 to get a comparison with the FFTW timing for the latter length) needs .40*.316*(400/467)*(362880/393216)) = .100 sec per FFT on a 467 MHz 21164. On a 195 MHz MIPS R1 CPU (SGI Origin 2000 workstation) FFTW needs 0.5*[5*262144*log2(262144) Flop]/[62 MFlop/sec] = .190 sec at n=262144 0.5*[5*362880*log2(362880) Flop]/[67 MFlop/sec] = .250 sec at n=362880 whereas Mlucas 2.7 needs (again extrapolating the 384K timing backward to 362880) .088 and .127 seconds, respectively, per FFT on the same hardware. The fact that it took me so much work to achieve these speeds is a testament to the speed of FFTW - the sample timings I sent to Steven Johnson (one of the authors of FFTW) last year were still generally slower than FFTW. However, "rolling one's own" (as it were) allows one to do lots of algorithm-specific optimizations not available to the FFTW folks. Since FFT-based large-integer arithmetic can do a pointwise (dyadic) squaring on the outputs of the forward FFT without them being ordered in any special way, one can do a forward decimation-in-frequency FFT, followed by a pointwise squaring of the (bit-reversal-reordered) data, followed by decimation-in-time inverse FFT, thus avoiding the need for explicit bit-reversal-reorderings of data (or matrix transposes, in the context of the 4-step FFT used by FFTW), for example. One can also combine the last pass of the forward FFT, the dyadic squaring and the first pass of the inverse FFT into a single pass through the data. Similarly, one can fuse the final pass of the inverse FFT, the rounding-and-carry- propagation step, and the first pass of the forward FFT, which both minimizes data movement (memory accesses) and allows one to propagate carries for several sub-blocks of the full array in parallel fashion. I'm sending a copy of this to both the Mersenne list and to Steven Johnson, the latter so he can correct any gross errors I might have made in my timings calculations for FFTW.) Cheers, Ernst _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: M(M(127)) and other M(M(p))
Chris Nash writes: I really hope that neither Will Edgington (with M(M(6972593))) nor Chip Kerchner (with M(M(1398269))) dedicated any computer time whatsoever to search for factors 2*k*M(p)+1 up to k=4. I didn't, except perhaps to have mmtrial verify that the smaller k's were sieved out. As Will's page http://www.garlic.com/~wedgingt/MMPstats.txt points out, since M(p)=1 mod 3, k cannot be 1 mod 3. Also, since M(p)=-1 mod 8 for odd p=3, k must be 0 or 1 mod 4 (otherwise 2 is not a quadratic residue of this supposed factor, the 8x+-1 condition). Thanks; I'll add this to the next MMPstatus file and to mmtrial.c. Should have thought of it myself, but quadratic residues are still new to me. Will _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: Updated info on M(M(p))
The list of known factors of iterated Mersenne numbers recently forwarded to these lists include all factors known to me, but the search limits have been significantly improved, some well before Nov. 1996 I believe. The MMPstats.txt file that I maintain is about to be updated to the following. If you do not have web access, feel free to email me; I can arrange to have it emailed to you automatically when it changes as part of the script that updates my web pages. Note the implication that I try to keep track of who is working on which exponents; this is simply to avoid duplication of effort. Will http://www.garlic.com/~wedgingt/MMPstats.txt mersfmt.txt mersenne.html Status of M(M(p)) where M(p) is a Mersenne prime $Id: MMP.status,v 1.49 1999/09/23 23:00:18 wedgingt Exp $ A factor will always be of the form 2*k*m + 1 where m = M(p) = 2^p - 1 is a Mersenne prime. 'U: k=61' is short-hand that trial factors = 2*k*m + 1 have been checked. The format is otherwise based on my usual Mersenne format, described in A HREF="http://www.garlic.com/~wedgingt/mersfmt.txt" mersfmt.txt /A. Note that, since m == 1 (mod 3), factors of M(m) cannot have k == 1 (mod 3) since 2*k*m + 1 == 0 (mod 3) in that case. Chris Nash pointed out on the Mersenne list (1999 Sep 22) that, for odd Mersenne exponents, k must be 0 or 1 mod 4, since, otherwise, 2 is not a quadratic residue of the supposed factor. Credit for first find of each factor (C: line) is given to the best of my knowledge. The one with my name is from my pre-GIMPS (see www.mersenne.org) data and probably pre-dates W. Keller's (also unpublished) 1994 discovery. Note that I have no P-1 factoring info for M(p) M(17) and no P-1 save files. M( M( 2 ) )P M( M( 3 ) )P M( M( 5 ) )P M( M( 7 ) )P M( M( 13 ) )C: 338193759479 # k = 20644229, Wilfrid Keller (1976) M( M( 13 ) )H: 2^55 # Charles F. Kerchner III, Prime95, stopped M( M( 13 ) )H: k=2199291723780 # " M( M( 13 ) )o: 3e9 # Warut Roonguthai, Factor95, stopped (no P-1 save file) M( M( 17 ) )C: 231733529# k = 884, Raphael Robinson (1957) M( M( 17 ) )C: 64296354767 # k = 245273, Wilfrid Keller (1983?) M( M( 17 ) )H: 2^60 # Charles F. Kerchner III, Prime95, stopped M( M( 17 ) )H: k=17592320263168 # " M( M( 17 ) )o: 3961649 # (unknown, no P-1 save file) M( M( 19 ) )C: 62914441 # k = 60, Raphael Robinson (1957) M( M( 19 ) )C: 5746991873407# k = 5480769, Will Edgington (Wilfrid Keller 1994) M( M( 19 ) )H: 2^60 # Warut Roonguthai, Prime95, stopped M( M( 19 ) )H: k=4398054899728 # " M( M( 31 ) )C: 295257526626031 # k = 68745, Warut Roonguthai (Guy Haworth 1983) M( M( 31 ) )C: 87054709261955177# k = 20269004, Tony Forbes (Wilfrid Keller 1994) M( M( 31 ) )H: 1984697089407967495 M( M( 31 ) )H: k=462098301 M( M( 61 ) )U: k=9363198284 # Landon Curt Noll, own program, stopped # Sturle Sunde, continuing 1999 Sep 22 M( M( 89 ) )U: k=13516351613# Landon Curt Noll, own program, stopped M( M( 107 ) )U: k=2016797660# Landon Curt Noll, own program, stopped M( M( 127 ) )U: k=12500 # Landon Curt Noll, own program, continuing M( M( 521 ) )U: k=2000 # Rob Hooft, mmtrial, stopped M( M( 607 ) )U: k=617 # Samuli Larvala, own program, stopped M( M( 1279 ) )U: k=17758437 # Conrad Curry, mmfac (see below), stopped M( M( 2203 ) )U: k=11356378 # Conrad Curry, mmfac, stopped M( M( 2281 ) )U: k=3026696 # Rob Hooft, mmtrial, stopped M( M( 3217 ) )U: k=304345 # Eric Prestemon, mmtrial, stopped M( M( 4253 ) )U: k=58 # Conrad Curry, mmfac, stopped M( M( 4423 ) )U: k=88 # Conrad Curry, mmfac, stopped M( M( 9689 ) )U: k=69034# Conrad Curry, mmfac, stopped M( M( 9941 ) )U: k=14000# Conrad Curry, mmfac, stopped M( M( 11213 ) )U: k=2573# Eric Prestemon, mmtrial, stopped M( M( 19937 ) )U: k=1501# Conrad Curry, mmfac, stopped M( M( 21701 ) )U: k=7123# Conrad Curry, mmfac, stopped M( M( 23209 ) )U: k=2731# Conrad Curry, mmfac, stopped M( M( 44497 ) )U: k=30169 # Chris Nash, by sieving possible factors, 1999 Sep 21 M( M( 86243 ) )U: k=271 # Conrad Curry, mmfac, stopped M( M( 110503 ) )U: k=7 # Will Edgington, mmtrial, stopped M( M( 132049 ) )U: k=40 # Will Edgington, mmtrial, stopped M( M( 216091 ) )U: k=19 # Charles F. Kerchner III, own program M( M( 756839 ) )U: k=23 # Charles F. Kerchner III, own program M( M( 859433 ) )U: k=32 # Charles F.
Mersenne: Mlucas 2.7: whoops #2
Oops - I just noticed that I mistyped the IP# for my ftp server in my postings yesterday - cut and paste, the fastest way to propagate errors throughout one's document. The correct ftp is ftp://209.133.33.182/pub/mayer/README Using my own terminology, a code which is at (or said to be at) a non-existent ftp site has a relative performance index of 0... Better luck this time, -Ernst _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: version 19 and confusion
Hi, I have been reading postings with interest... I have the idea that most people posting to the list are software programmers. I am a humble chemist more into 2,4-Dihydroxybenzene or antivirals..(Acyclovir??) I tried to install the version 19.0 expecting it on Win 98 to supplant my existing files...but no joy.. I am already testing a LL exponent, and all it did was create another version and give me other exponents to test.. I must admit the interface (GUI) on this is not as good as the Seti programme...which I indulged in for one month...Correct me , but I thought I would rather use my spare cycles for something a bit more tangible than looking at a short bandwidth with fft for something that is quite frankly..well...very UNTENABLE? As a non-programmer totally illeterate(!) user of Prime 18 with a Cyrix 333MII.. 8-( I feellike left out of the equation, if you forgive the pun... Really I want to know about the difference between floating point computation and integer based calculations. I really like this number theory exercise, primarily having read the work of Andrew Wiles on proving Taniyama-Shimura conjecture (Modular forms) -Eliptic equations...coupled with Galois Representations and Hecke algebras... I must admit, I like Hilbert best of all... Perhaps somebody can write a programme for pur integer based calculations.,??? Sorry, I am rambling All the best to Primenet and subscribers. feedback much appreciated... A poor chemist...(Could hardly understand Heisenberg's uncertainty principle...8-) Regards from U.K. Ian McLoughlin, Chematek U.K. Tel/Fax : +44(0)1904 679906 Mobile : +44(0)7801 823421 Website: www.chematekuk.co.uk _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
RE: Mersenne: QA testers call
At 09:36 AM 1999/09/23 -0700, Paul Leyland wrote: Hi Ken, that's a challenging project you're proposing. I'm very nearly tempted by this one, but the 6-year run time is a bit daunting. In the past I've devoted months to a single factorization but I've no real idea what I'll be doing in six years time or what hardware I'll have access to. To clarify, it is not a requirement that individual volunteers stay with the project the full run-time of the exponents they're working on. If/when quitting before completion, pass the intermediate file interim files on to those carrying on from there. I've been hunting mersennes since 1985, so the odds are I'll stick with it a while, barring major unexpected events. It's also not clear what the payback will be. The payback is that known-results exponents in completely new territory will be available against which any mersenne codes developed can be tested. The odds are low, but it's a nonzero probability that a prime could be found in the process. However, I've not yet completely ruled out volunteering, but need a bit more incentive and a bit more information. For instance, how big are the files I'd need to keep around, and how many for how long? (Note: file sizes appear to be the runlength size (ie: 112K = 114,688) x 4 plus 18 bytes for v18 and 22 bytes for v19) For v19: Exponent FFT,K Size of 1 save Limit file, bytes 199 96 393238 2323000 112 458774 2655500 128 524310 329 160 655382 3935000 192 786454 4598000 224 917526 525 256 1048598 6515000 320 1310742 773 384 1572886 902 448 1835030 1032512 2097174 1283640 2621462 1527768 3145750 1785896 3670038 2040 1024 4194326 2533 1280 5242902 3010 1536 6291478 3510 1792 7340054 4025 2048 8388630 4990 256010485782 5940 307212582934 6900 358414680086 7930 409616777238 Space, per se, is not a real problem (as long as it's not more than, say, 10Gb) but having to keep them safe for years means ensuring they are backed up and so forth. When we did RSA-155 my contribution to the relations (about 1/6 of the total) took 800Mb when compressed but needed to be preserved only for a couple of months and the copies at CWI acted as my backup, and vice versa. To work a worst case example, 79,300,000 run at InterimFiles=100 would leave 80 copies (79 interims the final) x 16MB or 1.3GB. It isn't necessary that any one person among the testing volunteers store more than a few exponents interim file sets, unless they are running many exponents in parallel. Another question: how hard are you planning to try to factor Mersenne numbers? With an effort you are planning, it would make sense to me to spend a cpu year or so trying to factor. Right; we are factoring to the default v19 depth, enough exponents to get at least 3 LL-testable candidates in each runlength. This *can* be trivially parallelized and I would be happy to contribute to this phase. With the resources I have, I can spend a PII-400 year factoring every week or two. I don't mind slipping in that much between my regular jobs. Paul, I'll be sending you some candidate exponents to continue factoring to the full depth. Ken Ken Kriesel, PE [EMAIL PROTECTED] _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
