Mersenne Digest Thursday, September 30 1999 Volume 01 : Number 635 ---------------------------------------------------------------------- Date: Wed, 29 Sep 1999 08:42:00 +1200 (NZST) From: Bill Rea <[EMAIL PROTECTED]> Subject: Mersenne: Mlucas and MacLucasUNIX on SPARC Sun Users, I tried the Mlucas_2.7x compiled with Sun's f90 version 2 and compared this against MacLucasUNIX v6.20. On the two ranges of exponents I tried Mlucas was about 15% slower than MacLucasUNIX, using 256k and 512K FFTs. Currently I'm double checking some exponents around 4,100,000 and doing LL testing on some around 8,300,000. One advantage Mlucas might have over MacLucasUNIX is that it can do FFT sizes other than 2^n, but even using the 224K and 448K FFTs for these exponent sizes, it was slower than MacLucasUNIX by about 8%. So for now SPARC users should probably stick to MacLucasUNIX, but I will look at the relative speeds again once MacLucasUNIX starts using a 1024K FFT, Mlucas' ability to do 640K and 768K FFTs should give it a speed advantage for quite a long time. Of course, MacLucasUNIX might also be faster by then :-) The compiler options I used were:- - -fast -libmil -xlibmopt -xarch=v9 I'm happy to try this again if someone can suggest a better set of options. Putting -xarch=v9 does make Mlucas run faster on systems that support it. Bill Rea, Information Technology Services, University of Canterbury \_ E-Mail b dot rea at its dot canterbury dot ac dot nz </ New Phone 64-3-364-2331, Fax 64-3-364-2332 /) Zealand Unix Systems Administrator (/' _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Tue, 28 Sep 1999 23:31:37 +0200 From: "Steinar H. Gunderson" <[EMAIL PROTECTED]> Subject: Mersenne: Re: FFTW for GIMPS? On Tue, Sep 28, 1999 at 07:43:17PM +0100, Brian J. Beesley wrote: >Alignment on 4-byte boundaries is quite sufficient for C floats. Ten- >byte reals (direct copies from FPU registers) are a problem When did using 10-byte reals become common? As far as I remember, you don't even have a store instruction for that. The 80-bit load is slower than the 64-bit load too, I think. /* 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, 28 Sep 1999 23:42:56 +0100 From: Tony Forbes <[EMAIL PROTECTED]> Subject: Mersenne: Search for a divisor of M_M_61. After longer-than-expected delay my program is now ready. You can download 'MFAC' from http://www.ltkz.demon.co.uk/AR2/MFAC225.ZIP and e-mail me for a range. MFAC searches for divisors of double-Mersenne numbers M_M_e = 2^(2^e-1) - 1 for not-too-large exponents e. (It can also look for factors of Fermat numbers F_e = 2^2^e + 1.). MFAC runs on any PC from a 486 upwards and on any system that supports MSDOS. You can even run it entirely from a bootable diskette. Memory usage is small and the files require less than a megabyte of disk space. The program is easily stopped and restarted. I am volunteering to coordinate a search for factors of M_M_61. Let d be a divisor of M_M_61. Then we know that d = N*(2^61 - 1) + 1. The parameters I intend to send out will set up MFAC to look for divisors of M_M_61 with N's in ranges of 204,204,000,000 To give some idea about timing, an AMD K6/2/400 will do a range in about 4 days. According to Will Edgington, up to N=18,726,396,568 has been done. (Note: My N = Will's 2*k.) However it may be that someone is seriously continuing the search. Therefore I suggest, unless you specifically want to do smaller N's, that I start handing out ranges from, say, N = 10^13. One possibility is that we do all divisors with N from 10^13 to 10^14 and mop up 0 to 10^13 later. A word or two of warning. Unlike GIMPS, where we can be confident of finding a new Mersenne prime within a reasonable time, it may be the case that we are attempting the impossible. All we can do is hope that (i) M_M_61 is composite, and (ii) it has a factor small enough to be discoverable. - -- Tony _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Tue, 28 Sep 1999 19:44:47 -0400 From: Pierre Abbat <[EMAIL PROTECTED]> Subject: Re: Mersenne: Re: FFTW for GIMPS? >When did using 10-byte reals become common? As far as I remember, you >don't even have a store instruction for that. The 80-bit load is slower >than the 64-bit load too, I think. Win32Forth can be compiled either way. Here's some of the code from FLOAT.F: B/FLOAT 10 = [IF] synonym FSIZE extended [ELSE] synonym FSIZE double [THEN] code fpush ( f: r -- ) ( fs: -- r ) \ push on simulated stack mov ecx, FSP [edi] fstp FSIZE FSTACK [ecx] [edi] fwait add ecx, # B/FLOAT mov FSP [edi], ecx next, end-code code fpop ( f: -- r ) ( fs: r -- ) \ push on real stack mov ecx, FSP [edi] sub ecx, # B/FLOAT js L$1 fld FSIZE FSTACK [ecx] [edi] mov FSP [edi], ecx \ fwait jmp L$2 _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Tue, 28 Sep 1999 22:33:27 -0400 From: George Woltman <[EMAIL PROTECTED]> Subject: Re: Mersenne: mprime V19--correct behavior or glitch? Hi, At 03:56 PM 9/27/99 -0400, St. Dee wrote: >I have all of my >machines set to get 45 days worth of work. Two of the machines, which >were nearly down to having only 45 days worth of work remaining, >immediately contacted PrimeNet, got an additional exponent each, and >factored that exponent to 64. This morning I awoke to find that >each machine contacted >PrimeNet overnight and unreserved the newly factored exponent, leaving >each machine with about 40 days of work remaining. Why is this? A bug. I thought the code was doing this: If all prior entries in worktodo.ini was more than 45 + 30 days then the exponent is returned. The "+30" is to avoid just what you are observing - frequent getting and releasing of exponents as the "rolling average" fluctuates. This is a lot like a thermostat where the heat comes on at 69 and off at 71 when you set the desired temperature to 70. The code was actually releasing the exponent if the prior exponents exceeded 45 days and the prior exponents plus this exponent exceeded 45 + 30 days. Now that it is common for exponents to take longer than 30 days, the bug has surfaced. I shall fix the bug. Keep up the good work, George _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Tue, 28 Sep 1999 20:08:12 -0700 (PDT) From: =?iso-8859-1?q?Olivier=20Langlois?= <[EMAIL PROTECTED]> Subject: RE: Mersenne: Re: FFTW for GIMPS? Hi Paul, - --- Paul Leyland <[EMAIL PROTECTED]> a écrit: > > From: Olivier Langlois > [mailto:[EMAIL PROTECTED]] ... > > Actually, we at Microsoft Research in Cambridge have > seen similar effects > when compiling and running FFTW code. Our discovery > is that the alignment > of FP data values is critical. Get it wrong, and > performance can plummet. > Unless you set the alignment explicitly, it will be > wrong approximately half > the time. > > Jonathan Hardwick investigated this effect as part > of his research into > high-performance computing. He gave an internal > seminar (which is where I > learned about it) and wrote it up in detail. The > full details are at > http://www.research.microsoft.com/users/jch/fftw-performance.html I agree with you that data aligment is an important issue for performance. Non-aligned data need 2 memory read to be fetched. I was aware that MSVC++ 6 is superior than some other compilers on this aspect because it does an AND on the stack pointer with 0xFFFFFFF8 to be sure that local variables will be aligned within an 8 bytes boundary. However, MSVC FPU registers allocation and assignement algorithm could be greatly improved(that was my point in my previous e-mail and Assembler listings generated by MSVC from FFTW are great to see what I mean). MSVC almost never use all 8 FPU registers. It seems like your optimizer is good on a statement basis but as soon as you have a sequence of short FP instructions, it does a very bad job. With these unused registers: - - it could start a new FP operation instead of storing back to the memory the result of an unfinished FP operation which waste a few CPU cycles. - - it could use them to store temporary variables and reduce memory access. With a better FPU registers allocation and assignement algorithm than the actual one, I wouldn't be surprise to see FFTW 20-30% faster than now with MSVC. While we're at it, there is a simple optimization that MSVC doesn't perform. When there is an expression like that: x % n where n is a numeric constant of the form 2^y and y <= 32. The compiler could replace this by x & (n-1) (An optimization using a Mersenne Number :-) instead of doing a costly division like it is done right now. Greetings Olivier Langlois http://www3.sympatico.ca/olanglois - [EMAIL PROTECTED] Nortel Networks 514-818-1010 x46659 Montreal, Canada __________________________________________________ Do You Yahoo!? Bid and sell for free at http://auctions.yahoo.com _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Tue, 28 Sep 1999 20:22:43 -0700 From: Spike Jones <[EMAIL PROTECTED]> Subject: Mersenne: graphical interface for gimps Instead of a boring status bar, how about a graphic of a caterpillar gnawing away on a leaf? It starts out as a full leaf and disappears as the little beastie devours his sustenance. Have an outline of the original leaf for size comparison. That would be cool: have it turn into a butterfly at the end. Or if the exponent is prime, have it turn into a pile of gold or something. {8^D spike _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Wed, 29 Sep 1999 11:56:32 +0200 From: Sturle Sunde <[EMAIL PROTECTED]> Subject: Re: Mersenne: Search for a divisor of M_M_61. > According to Will Edgington, up to N=18,726,396,568 has been > done. (Note: My N = Will's 2*k.) However it may be that someone > is seriously continuing the search. That is correct: <URL:http://www.garlic.com/~wedgingt/MMPstats.txt> You could at least check this page (which should be well known) and email the one who is listed there as working on the exponent (me) before handing out ranges. > Therefore I suggest, unless you specifically want to do smaller N's, > that I start handing out ranges from, say, N = 10^13. One possibility > is that we do all divisors with N from 10^13 to 10^14 and mop up 0 to > 10^13 later. I have been factoring a bit above k=10^13 already, but with several large gaps below. Start higher if you want to avoid duplicating work. - -- Sturle URL: http://www.stud.ifi.uio.no/~sturles/ Er det m}ndag i dag? ~~~~~~ MMF: http://www.alladvantage.com/go.asp?refid=BUP399 - St. URLe _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Wed, 29 Sep 1999 16:11:56 -0400 From: George Woltman <[EMAIL PROTECTED]> Subject: Mersenne: Version 19 - release candidate #1 Hi all, At Scott's request, a computer ID is now required (one will be assigned if you don't specify one). The RdtscTiming undocumented feature has been made available plus some minor bug fixes. The math code is unchanged. I'll post the updated source code shortly. There is one report that the NT service version crashes in Windows 2000. Have there been any success stories in this environment or is this an isolated incident? Please respond by private email. Prime95 can be downloaded at: ftp://entropia.com/gimps/p95b.zip 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 The Windows NT service version is at: ftp://entropia.com/gimps/ntb.zip Regards, George _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Wed, 29 Sep 1999 18:01:17 -0400 From: "Allan G. Schrum" <[EMAIL PROTECTED]> Subject: Mersenne: New "Feature": ping-pong exponents This probably isn't a problem, but it is an interesting feature of V18.1.1 prime95. Just before a system backup, prime95 fetched a new exponent to work on. A few hours later, I stopped the machine to do a backup which took approximately 12 hours. When starting the system back up, prime95 decided I had too much work to do and gave back the exponent. A day later, prime95 decided it was time to get another exponent and so I have yet another exponent to test. Obviously, prime95 is trying to determine the approximate "hours per day" it is running to get X-days of work and I happened to hit that threshold (both coming and going) that caused this strange game of Ping-Pong. I don't think anything really needs to be done (unless you really want to add some hysteresis to the exponent check-out procedure), but it was interesting to watch. - -Allan _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Wed, 29 Sep 1999 19:05:08 EDT From: [EMAIL PROTECTED] Subject: Mersenne: F24 resolved - official announcement TECHNICAL NEWS RELEASE (29 Sep 1999) DEEPEST COMPUTATION IN HISTORY, FOR A YES/NO ANSWER Contact: Dr. Richard Crandall Director Center for Advanced Computation Reed College, Portland Oregon (503) 777-7255 email: [EMAIL PROTECTED] What is believed to be the deepest computation -- for a simple "yes/no" or "1-bit" answer -- in history has just been completed by a team of three investigators: Ernst Mayer, formerly of Case Western Reserve University, Cleveland, Ohio; Jason Papadopoulos of the University of Maryland, College Park, Maryland; and Richard Crandall of the Center for Advanced Computation, Reed College, Portland, Oregon. The computation involves a gargantuan, mysterious number called F24, the twenty-fourth Fermat number. F24 is over 5 million decimal digits in length, and the three investigators have answered the question: "is F24 a prime number?". The answer, based on their intensive computation, is "no." This means that there must exist proper factors of F24, though not a single explicit factor is yet known. (See end of article for background on the celebrated Fermat numbers.) Mayer and Papadopoulos used independent, floating-point "wavefront" implementations of the rigorous, classical Pepin primality proof; which runs were completed on 27 and 31 Aug 1999 respectively, ending up in complete agreement on the final Pepin residue, said residue not equal to (-1) as required for primality. During these "wavefront" runs Crandall used a pure-integer convolution scheme in parallel mode (i.e. running on many computers simultaneously), to check the periodically deposited wavefront residues. With this integer verification, the proof is considered rigorous: there is no doubt that F24 is composite. The mathematical details will be published later (a preprint of the three authors' paper is available at www.perfsci.com/free/techpapers). Many colleagues of the three investigators contributed to this massive computational project (see below for detailed acknowledgements). F24 = 2^(2^24) + 1 at over 5 million digits dwarfs the current largest known prime 2^6972593-1, which is a "mere" 2 million digits (see www.mersenne.org, www.perfsci.com, www.entropia.com). To convey the scale of the computation, consider that the Pixar-Disney movie "A Bug's Life" needed about 10^17 (one hundred quadrillion) computer operations for its complete rendering, yet essentially the same number of operations went into the F24 proof. So the amusing notion is: for 10^17 operations you can either get a feature-length state-of-the-art synthetic movie, or for similar computational cost you can get a 1-bit answer (prime/not prime). Fermat numbers are numbers of the form Fn = 2^(2^n) + 1. Written in binary the n-th Fermat number consists of a binary one, followed by 2^n zeros and a trailing one. For example, in binary F2 = 100001 and F4 = 100000000000000001. Each time you increase the index n by one, the number of binary zeros, and thus the number of digits (in either binary or decimal form) also roughly doubles. P. Fermat conjectured in the early 1600's that each of the Fn is prime. He had in hand the first five examples F0 = 3, F1 = 5, F2 = 17, F3 = 257 and F4 = 65537, each of which being indeed prime. However, unlike his celebrated "last theorem" recently proved by A. Wiles, Fermat's conjecture regarding the primality of the Fn turns out to be about as wrong as can be. Not a single prime Fermat number is known beyond F4. For example, F5 = 4294967297 is divisible by 641, and every other Fermat number has either exhibited factors, or remains of unknown character (prime/composite). When factoring algorithms fail to produce an explicit factor, the Fermat number in question can still be subjected to a Pepin test, a deterministic test of primality. This test requires a sequence of squarings of numbers, a member of the sequence being generally as large as the Fermat number under test, and one must do as many such squarings as there are binary zeros in the Fermat number in question. The primality test for F24 thus requires 16777215 squarings, each such squaring being of a number over five million decimal digits in length. Even though it is now generally believed that are no more prime Fermat numbers beyond those found by Fermat himself, the testing of these numbers has proved to be a valuable exercise, since each new test tends to occur, for the given era, at the edge of feasibility on state-of-art computer hardware, not to mention at the fringe of algorithm development. There have also been important theoretical and algorithmic advances spurred by such work, and many of the fundamental algorithms used for the Fermat numbers are also widely used in other areas - for example, the two floating-point Pepin tests of F24 each used an efficient squaring algorithm based on a procedure called the fast Fourier transform (FFT), which is ubiquitous in the field of electronic signal processing. The pure-integer convolution that verified the Pepin test also has wide application in arbitrary-precision arithmetic. In developing their separate implementations, each member of the team (Mayer, Papadopoulos, Crandall) made advances in the matter of implementation of the FFT and convolution algorithms on modern microprocessor architectures. We note that F22 was resolved (as composite) in 1993. Various Fermat numbers beyond F24 have been attributed at least one explicitly known small factor (see http://vamri.xray.ufl.edu/proths/fermat.html for the current computational knowledge pertaining to Fermat numbers), so that the next unresolved case is the monstrous F31 which (at over 600 million decimal digits), even with the aforementioned algorithmic advances, is out of reach with current technology. We estimate 10000 years processing on hardware of current vintage be required to resolve F31. However, history is replete with underestimates on future machinery and ingenuity. We are confident that with ever-faster processors and further algorithmic advances, in particular those aimed at implementation of the Pepin test on massively parallel computer hardware, a test of F31 may come within the next two decades. And this perhaps surprisingly optimistic estimate is made even without the benefit of quantum computers, nanotechnology, and so on; breakthroughs in any of these areas could alter the assailability of F31 dramatically. Background on investigators: Ernst W. Mayer was until recently on the faculty of Engineering of Case Western Reserve University in Cleveland, Ohio. He is currently working as a freelance computational number theorist and algorithm developer out of his home in Cupertino, Calfornia. Jason S. Papadopoulos is a graduate student in the Electrical Engineering school at the University of Maryland, College Park. His interests include cryptography, computational number theory, and high-performance scientific computing. Presently he works for 3S Group Inc, a Vienna, VA-based firm specializing in encryption hardware. Richard E. Crandall, author, lecturer and computationalist, is the Director of the Center for Advanced Computation, Reed College, holding also the title of Apple Distinguished Scientist. His algorithms have previously been used to resolve the character of F22, and to discover record primes such as the last several largest-known Mersenne primes. Acknowledgements: The three investigators gratefully acknowledge the theoretical and engineering contributions from J. Buhler, H. Lenstra, J. Klivington, C. Pomerance, J. Selfridge, P. Montgomery, G. Woltman. C. Curry, P. Wellin, R. Knapp, S. Wolfram. Alex Kruppa and the staff of the Infohalle der Fakultaet fuer Informatik an der Technischen Universitaet Muenchen lent considerable processing power and personal maintenance time to the integer proof runs. The first-completed floating- point run was performed on a Silicon Graphics R10000 Octane workstation - the investigators thank J. Alexander of Case Western Reserve University for his generous donation of machine time. Thanks are also due to 3S Group Incorporated for the extended use of a Sun UltraSPARC-1, used as the second floating-point machine. The Number Theory Foundation donated additional machinery for the final stages of the pure-integer proof, and a key segment of said proof was carried out on Apple Computer's newly announced G4 processor, which provides giga-op-level performance. A Reed College team of staff and students: N. Essy, B. Hanson, C. Chen, J. Dodson, R. Richter, W. Cooley, J. Heilman, D. Turner, (and from Univ. Georgia) C. Gunning finished in glorious and selfless fashion the last stages of the rigorous integer proof. For more information: Consult the algorithm website www.perfsci.com _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Wed, 29 Sep 1999 22:35:21 -0400 (EDT) From: "Vincent J. Mooney Jr." <[EMAIL PROTECTED]> Subject: Re: Mersenne: graphical interface for gimps Neat Idea !! At 08:22 PM 9/28/99 -0700, you wrote: >Instead of a boring status bar, how about a graphic of a >caterpillar gnawing away on a leaf? It starts out as a full >leaf and disappears as the little beastie devours his sustenance. >Have an outline of the original leaf for size comparison. >That would be cool: have it turn into a butterfly at the end. >Or if the exponent is prime, have it turn into a pile of gold >or something. {8^D 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 ------------------------------ Date: Wed, 29 Sep 1999 23:42:44 -0400 From: "Chris Nash" <[EMAIL PROTECTED]> Subject: Re: Mersenne: graphical interface for gimps > >Instead of a boring status bar, how about a graphic of a > >caterpillar gnawing away on a leaf > Neat Idea !! I love the thinking behind this... after all, it seems fashionable these days to offer downloadable 'skins' for your mp3 player or whatever - the world is obsessed with multimedia :) Who knows, maybe some one out there will write a Prime95 viewer that sits there watching George's window for text output and show it as a cute animation in the 'skin' of your choice... in fact, with all the talk about the gui on here, I'm surprised someone hasn't tried that already :) Oh, it would have to take zero processor time, of course :) Chris Nash Lexington KY UNITED STATES _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Thu, 30 Sep 1999 11:05:08 +0100 From: Gordon Spence <[EMAIL PROTECTED]> Subject: Mersenne: Re: Very Large Exponents I am running the new V19 software as part of the QA program and I am tempted to devote one of my V18 machines to testing some of the very large exponents (60m+). What I would like to know is where can I get a list of the big exponents and how far they have been trial factored if at all. It would be kinda fun to do some trial factoring on exponents that have had no tests done at all, and even to do a full test on one of the 79m range. Yes I know it will take years (and years), but I did an LL test on a 20m exponent on a PII-300... regards Gordon _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Thu, 30 Sep 1999 13:26:23 +0200 From: "Steinar H. Gunderson" <[EMAIL PROTECTED]> Subject: Re: Mersenne: Re: Very Large Exponents At 11:05 30.09.99 +0100, Gordon Spence wrote: >What I would like to know is where can I get a list of the big exponents >and how far they have been trial factored if at all. To get some BIG exponents assigned, your best bet would probably be talking to Ken. I guess he's coordinating it as a part of the QA program. In case you don't have it, he's e-mail address is [EMAIL PROTECTED] . /* Steinar */ _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Thu, 30 Sep 1999 05:01:21 -0700 From: Eric Hahn <[EMAIL PROTECTED]> Subject: Re: Mersenne: Factors Everywhere Will Edgington wrote: >Eric Hahn writes: > > I've come up with this SWAHBI (like a SWAG, but an idea > instead of a guess). > >Hm, "silly, wild *ssed, half-baked idea" ? That's not an acronym >I've seen before.:) Since I've been asked privately on numerous occasions, I'll post here for everybody... SWAHBI is an acronym for "silly, wild-*ss, hare-brained idea!", but Will's interpretation will do just fine too. :) Actually, as I've told a couple of people, I shouldn't insult rabbits like that, even though the ideas tend to breed like them. <G> Eric Hahn ...Who has found the 51-bit factor 1,152,058,136,977,799 of M(79,299,931)...and still searching on M(79,299,959). _________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Fri, 1 Oct 1999 04:10:27 +0100 From: "Ian L McLoughlin" <[EMAIL PROTECTED]> Subject: Mersenne: Purpose... Forgive me, But, I seem to be subscibing to a project which is utilising processors 'world-wide' for several purposes: A) For Programmers to enhance their skills at the 'cutting edge' B) For Web based people to increase their knowledge within a distibuted network. C): I realise that a lot of what is contributed is going to be used in encryption et.al... Since I am based in Europe, and denied certain facilities from the web as to U.S. encryption bit encoding ( U.S. and Canada keeping it for themselves..?!)... Is their an auterior motive behind this...??????? Just a thought..... 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 ------------------------------ End of Mersenne Digest V1 #635 ******************************
