Re: Mersenne: version 19 and confusion
On Fri, Sep 24, 1999 at 02:24:32AM +0100, Ian L McLoughlin wrote: Really I want to know about the difference between floating point computation and integer based calculations. To put it short: FP is _much_ faster on all CPUs. Even on the Cyrixes, which have very slow FP. Perhaps somebody can write a programme for pur integer based calculations.,??? Sorry, it would be even slower than using FP-only. If you'd like work well suited to your Cyrix, you can always do factoring -- there is an integer- only version of the factoring algorithm, which is automatically used if you say you have a Cyrix or a 486. /* Steinar */ _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: Re: Linux error 2250 (was Front-end design)
On Thu, Sep 23, 1999 at 05:45:39PM -0400, George Woltman wrote: Incidentally, can anyone explain why under v19.0.2 I'm getting "ERROR 2250: Server unavailable" messages? Someone told me that glibc-2.1 (as compared to v18's libc5) uses different files or network setup or something. I am a Linux know-nothing, so perhaps a list member can enlighten all of us. Please give us some more debug info, then :-) What does error 2250 provoke? This sure doesn't come from glibc, but from the PrimeNet code. The problem is finding out what provokes this error. (Hint: give us the content of the variable `errno' and let's see what we can find :-) ) /* 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
Mersenne: Re: Conflict with Windows Schedule agent?
On Thu, Sep 23, 1999 at 06:52:40PM -0400, Jud McCranie wrote: The only thing (other than the regular system stuff) that I have running is Prime95. Any ideas? Try to turn off Prime95 and then retest, OK? :-) It's not easy to say if Prime95 is the problem, without trying without it. /* 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: Decamega Tests (was: RE: Mersenne: GIMPS client output)
Philippe Trottier wrote: 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) *snap* Sounds like loop unrolling is what you're talking about. Most modern compilers (try to) do this already automatically. However, I've experimented on different variations of this with the Linux source to, I think, v16 or so, where it seemed possible to attain small benefits from various variations of look-unrolling. The biggest problem here is that the number of iterations isn't divisible by any fixed amount. Because of that the last few iterations need to be done "manually" outside the unrolled block. The main advantage of such unrolling comes from not needing to check for the number of timed events present in Prime95/mprime between each iteration - due to cache considerations actually copying the whole FFT code out as many times as needed instead of just using calls to it is probably even worse. I've posted about this suggestion before on this list, so I hope the possible optimizations have been taken into consideration in v19 already, altough with the exponent increasing the FFT code is starting to take more and more time and the optimization of all the rest of the code become less important. I seem to also have forgotten the rest of the optimizations I've toyed with ; -Donwulff _ 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
Robert van der Peijl wrote: Now, everybody, _PLEASE_: If you're thinking How about a nifty gadget such-and-such?. Let's NOT send all THAT to the mailing list! The list would get swamped in tons of traffic. So please, okay? Though you ask this, I find the topic rather appropriate for the list, especially given the angle of "HOW can we visualize the process of mathemathical operations?". So, unless somebody comes up with a better avenue for discussing it, or threatens me with a hammer, I'll take my best shot... It's _not_ a call for discussion of every little knob and letter in the proposed GUI, though! Actually, the main reason I do is because there's something I've been for long hoping from the "distributed computing" projects, in vain... Something so obivious and simple I'm wondering why it hasn't already been included, if it's just me or... Oh well ;) Anyway, rather than keep you all in suspense, which sounds tempting too, I'll just tell it since I'm dying to see this one out there: How about a grpah of how much CPU-time the calculations are taking? One of the strongest drawbacks to the various distributed computing projects is that there's simply no way to know how much CPU your "real work" is takng at any given time, it's just 100% CPU utilization all the time. This is pretty dumb, especially when you have a program running that seems to know just how much spare time there is in the system at any given time. Now, for the Unix client there's a real problem here. Yes, I agree the main client should be a console application. I'm wondering if it's possible to build an executable that runs both console and X, though..? The big problem is that we don't have enough data outside of the program to draw almost any graphics... getting the structure-definitions of the intermediary files could be a good start, though. Other suggestions for graphics: (Comments in private, though, preferably, if there's anything new coming out I can post summaries). I'd work on this myself if I had the time and source, being I don't... - progress bars like "Go!Zilla", using various bitmaps that are slowly revealed. Images related to computer math theory would be preferred. - comparements to "worst competitors" on the CPU-years category etc, preferably with runnign real-time stats, which brings us to... - simple chat system. With the Internet connectivity routines already in place, allowing chatting with other people running the Prime95/mprime client shouldn't be much of a chore. - for checking large Mersenne numbers, I think the only kind of "status display" really making sense would be a multi-color graph of the status of the full Mersenne search. Many of these suggestions seem to also require changes to the existing PrimeNet server, or even a new server to take off some of the "non-essential chores" like the competitors world check status displays, which is another reason why I think this can't be just brainstormed in private, disconnected from all the rest of the GIMPS effort, like we were operating in a vacuum. -Donwulff _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Re: Mersenne: Important info on M(M(p)) from Wilfrid Keller
Lucas Wiman [EMAIL PROTECTED] writes [...] when I found out than Curt Noll had started an attack on M(M(127)) with superior hardware. I imagine that by now he has carried the search much further. This is further evidence for why GIMPS is such a good idea! (as if we needed more) Well, yes ... but in practice when you work on a problem with considerably more powerful hardware than has previously been applied to it, there is little cost in starting again from scratch, and it double- checks the work that has already been done. If Curt Noll and you have been working together, your computer time would not have been wasted, nor would (presumably) much of his. This is the beauty of distributed computing projects, but this illistrates how *key* centrilization is. Of course, soon after Curt started working on M_M_127 I collaborated with him - by retiring! Now, I think that it might be a nifty (tm) idea if GIMPS/primenet were to start looking for factors of double Mersenne numbers. If I understand correctly, much of the code is already written (changes to the P-1 code, and the normal factoring code), and I'm sure that such things could interest mathematicians more than finding the next Mersenne prime. The only feasible approach for M_M_61 and above is trial-division. I recently blew the dust off by my program MFAC and gave it a run. For M_M_61 it processes divisors N*M_61 + 1 on an AMD/400 at about 2.2 billion N's per hour. (6 billion/hour for M_M_31.) If people are interested, and unless someone else can do better, after a bit of tidying up I can make this program available. Then we need a mechanism for handing out work. I am happy to volunteer, but it will have to be done manually. -- Tony _ 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 23 Sep 99, at 16:18, Robin Stevens wrote: 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 That's enough of a reason to convince me. Also, running X on a system increases substantially the memory requirements of a system and its need for either substantial backing store or fast network support. As it is, a linux mprime client / room warmer (without X) is happy with a 170 MB disk (practically free from the junkyard). 16 MB of RAM is adequate, 32 MB is comfortable 64 MB is overkill. You may have noticed that SDRAM prices had already doubled in a month even _before_ the Taiwan earthquake - which, one suspects, will not improve the supply situation - so the extra 16 MB of RAM you _really need_ to run X is going to cost you something of the order of $25. And you need a graphics card to run X, too - my linux mprime client doesn't contain one! Regards Brian Beesley _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: Mlucas 2.7x on SPARC
Alex Kruppa has done some SPARC timings of Mlucas 2.7x compiled using the newish SPARC f90 v2 compiler, which appears to be much better than v1. (At last, 64-bit loads and stores - hooray! Seems ridiculous for such a thing to be worth cheering about, but like I said, v1 was *really* bad.) He writes: I've got a binary that needs 0.183 secs / iteration with the 256K array size now. Seems the Fortran section of Sun Compilers borrowed a few smart guys from the C section. :) Mlucas_2.7x on a UltraSparc II 300 Mhz is almost as fast as on a 400 Mhz Alpha 21164. Hi, Alex, and many thanks for the timings. That sounds promising - note that the latest README file has a complete set of timing/accuracy tests for cases from 64-4096K. I tried all sorts of compiler flags - unfortunately, the optimization flags are not linear, especially -O5 tends to produce much slower code than -O4 when combined with other flags. I see similar weird slowdowns using the -O5 compile option on some (not all) Alpha CPUs (generally the older ones.) I wonder if both compilers are doing similar "optimizations" at -O5. I'm using -fast -libmil -xlibmopt -fnsyes now, which seems to give close to optimal performance. As long as it correctly runs the self-tests, faster is better. Note that a few of the self-tests will give some roundoff warnings, especially if the compiler in question doesn't support extended-precision floats, used (when available) by Mlucas for sincos and DWT weights tables initializations. I dont know whether this is also optimal on other types of UltraSparc, I only have Ultra60s for testing. Let me know where I can ftp the binary, and I suspect we'll soon get lots more SPARC timings - it's a popular Unix platform. Thanks, Ernst _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: Mlucas 2.7: accuracy
David Willmore writes: Oh, you're having a bad day, now: mars-test cat p02608007.stat M( 2608007 ): using an FFT length of 131072 this gives an average19.8975143432617 bits per digit M 2608007 Roundoff warning on iteration 995 maxerr = 0.40625000 ... M 2608007 Roundoff warning on iteration 46031 maxerr = 0.4375 M 2608007 Roundoff warning on iteration 46042 maxerr = 0.5000 FATAL ERROR...Halting execution. Hi, David - Yep, it looks a like I better set s.t. like 2.6M as the upper limit for 128K. v2.7 gives away a bit of accuracy for the sake of speed. Right now, your only option is to run from scratch using v2.6c (as long as it's the first exponent in the range file, the run should be OK), or (what may be faster) use 2.7x at 160K, e.g. by explicitly listing the run length in interactive mode - delete or rename the worktodo.ini file and enter s.t. like Mlucas == perhaps add output redirection on this line... 2608007,163840 return return You can redirect the output to a file and use crtl-Z and bg to restart the job in background mode, allowing you to log out. I'm working on adding some kind of automated error detection/FFT length resetting to the next release, but it adds a lot of program logic and hence takes time to do - I didn't want to wait for that before releasing a beta version. Thanks for the info - keep those bug/problem reports coming. -Ernst _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: Iteration meter (hooray, a GUI!)
Linux folks,
Here's my small GUI program. It uses the framebuffer device to produce
a graph of the iteration time (ie. lower is better). It assumes a couple
of things:
1. You already have framebuffer set up.
2. You're running mprime v19.
3. You know what you're doing. (Don't come running to me if you need help
compiling, setting up your framebuffer device etc.)
4. Your fb device is using 32 bpp (NOT 24, 16, or 8 bpp...)
5. You like weird colours.
Run (after compilation):
./mprime -d | itermeter
Every time mprime would normally output a line, a flashy bar comes up.
If your X resolution is the same as your fb resolution (and if you run
32 bpp in X), try switching to X for a bit of a weird effect :-)
Don't expect this to ever be ready for a general release. It's just a
piece of crap that I smacked together in 10-15 minutes. (Hope nobody
minds about my 3K-attachment -- the file wasn't that big, so I didn't
bother to FTP upload it etc.)
/* Steinar */
--
Homepage: http://members.xoom.com/sneeze/
/*
* made by Sesse 24.9.99
* no copyrights as of current -- have fun
*/
#include sys/mman.h
#include fcntl.h
#include unistd.h
#include stdio.h
/* w/h = actual width/height */
/* fw = virtual width */
/* fbdev = framebuffer device */
#define w 800
#define fw 1024
#define h 600
#define fbdev "/dev/fb0"
void main(void)
{
int fd = open(fbdev, O_RDWR);
int i = 16;
char *buf = mmap(NULL, fw*h*4, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
float max = 1.0f;
memset(buf, 0, fw*h*4);
while (!(feof(stdin))) {
int ijunk;
float fjunk, iter_time;
int y, x, p;
float barheight;
scanf("Iteration: %d / %d [%f%%]. Per iteration time: %f sec. (%d
clocks)",
ijunk, ijunk, fjunk, iter_time, ijunk);
do {} while (getchar() != '\n');
if (iter_time max) iter_time = max;
barheight = (float)iter_time/(float)(max)*(float)(h-32);
p = 0;
for (y = h-16; y h-16-barheight; y--) {
int rcomp = 0, gcomp = 0, bcomp = 0;
float val = (float)(++p) / barheight;
/* 0/4: 100% red */
/* 1/4: 50/50 red/green */
/* 2/4: 100% green */
/* 3/4: 50/50 green/blue */
/* 4/4: 100% blue */
if (val 0.5f) {
rcomp = 255 - (val * 512.0f);
}
if ((val 0.25f) (val 0.5f)) {
gcomp = (val - 0.25f) * 1024.0f;
}
if ((val 0.5f) (val 0.75f)) {
gcomp = 255 - ((val - 0.5f) * 1024.0f);
}
if (val 0.5f) {
bcomp = (val - 0.5f) * 512.0f;
}
buf[4*fw*y + 4*i] = buf[4*fw*y + 4*i + 1] = buf[4*fw*y + 4*i +
2] =
buf[4*fw*y + 4*(i+16)] = buf[4*fw*y + 4*(i+16) + 1] =
buf[4*fw*y + 4*(i+16) + 2] =
0xff;
buf[4*fw*y + 3] = buf[4*fw*y + 4*(i+16) + 3] = 0;
for (x = i+1; x i+16; x++) {
buf[4*fw*y + 4*x] = bcomp;
buf[4*fw*y + 4*x + 1] = gcomp;
buf[4*fw*y + 4*x + 2] = rcomp;
buf[4*fw*y + 4*x + 3] = 0;
}
}
/* draw vertical top line */
memset(buf + 4*fw*(h-16-(int)barheight) + 4*i, 0xff, 64);
i %= w-34;
i += 16;
}
close(fd);
}
Mersenne: V19 source code
Hi, At 05:27 PM 9/23/99 +0100, Chris Jefferson wrote: Where can I get the most recent Prime95 source code from? I've just uploaded the v19 source code. You can download it from http://www.mersenne.org/source.htm The only restriction I've placed on the code is that if you use it to find Mersenne primes, you must adhere to the GIMPS prize rules at http://www.mersenne.org/prize.htm The v19 code is much more usable in other math projects. It would be interesting to see if it could be adapted to Proth prime searching (and whether it is enough faster to be worth the effort) or some other new number theory projects. Regards, George _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne Digest V1 #631
Mersenne Digest Friday, September 24 1999 Volume 01 : Number 631 -- Date: Wed, 22 Sep 1999 22:02:22 -0700 From: Kevin Sexton [EMAIL PROTECTED] Subject: Re: Decamega Tests (was: RE: Mersenne: GIMPS client output) "Brian J. Beesley" wrote: On 20 Sep 99, at 1:06, Rick Pali wrote: The only question that comes to mind is if you had to plough through factoring before you got to the LL test...but then I realise that you still wouldn't be done if that were true. You don't have to pre-factor, if you choose "Test" or "Time" from the "Advanced" menu. I signed up for an exponent in the 33mil range and the factoring alone took 13 days on a P3-500. Ah, so we're maybe not doing enough trial factoring. I guess your completion time is about a year; trial factoring should take between 5% and 10% of the time for a LL test, 13 days is only about 3.5%. I think we should probably go one bit deeper, this would double the trial factoring time - but would save the whole year, if you managed to find a factor. I'd originally does it for testing purposes, but after that I've just got to let it continue. :-) Well, why not? In a year's time, I'd love to see some numbers on how many signed up for tem million digit numbers and later quit for smaller exponents... I think you need to be a true enthusiast to take on a single test taking ~ 1 year. Lots (attracted by ca$h) won't realise what it means, for a week or two, may then drop out 8-( To avoid this happening to too many people, I think we should be a bit more upfront that testing a 10 million digit number is going to take about a year, even on a state-of-the-art system. I have several fastish systems - a couple of them are running QA stuff at the moment - I may voluntarily take on a 10 million digit number on _one_ of them, but I certainly wouldn't choose to run tests of that length on _all_ of them! Regards Brian Beesley _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers 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. _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers -- Date: Thu, 23 Sep 1999 01:37:11 -0500 From: Ken Kriesel [EMAIL PROTECTED] Subject: 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)
Mersenne: trial factoring using P-1's GCD
I've been wondering about this lately... If we are to begin P-1 testing on larger exponents, this implies lower trial factoring limits (though possibly only by 1 or 2 bits). Now, P-1 requires an investment of a GCD on two numbers each of similar size to Mn. So, since we are investing this much (computational) engery in a GCD, why not cram in as many factors as we can? Would it be possible to find multiply the (a^q-1) mod Mn by small (possible) factors skipped due to the lower factoring bounds faster than it would to directly check these possible factors? Gack, that was a bit unclear, say that k*n+1 divides Mn, k is non-B1-smooth. Which would take more time, checking (directly) to see if k*n+1 divides Mn, or multiplying (a^q-1) by k*n+1? (assuming k*n+1 is around 64 bits) Lucas _ 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)
Sounds like loop unrolling is what you're talking about. Most modern compilers (try to) do this already automatically. However, I've experimented on different variations of this with the Linux source to, I think, v16 or so, where it seemed possible to attain small benefits from various variations of look-unrolling. The biggest problem here is that the number of iterations isn't divisible by any fixed amount. Because of that the last few iterations need to be done "manually" outside the unrolled block. The main advantage of such unrolling comes from not needing to check for the number of timed events present in Prime95/mprime between each iteration - due to cache considerations actually copying the whole FFT code out as many times as needed instead of just using calls to it is probably even worse. There's another trick to this, primarily useful in assembler not C programming... Say you unroll something 16 times Take teh actual iteration count modulo 16, and JMP into the loop at that offset to start with the repeat counter set to the count/16. i.e. if you need to do, say, 60 iterations of the inner code, thats 48 + 12, so you set the loop count to 3, and jump to the 4th block of the 16 (16-12 = 4) Anyways, prime95 is HEAVILY unrolled, using assembler macros to generate the inline linear inner 'loops'. -jrp _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: Factors Everywhere
Eric Hahn writes:
[I've already replied in detail to Eric privately.]
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.:)
What I'm looking for is the following two items for *all*
Mersenne numbers 2^p-1 where p is prime and p1:
1) All known factors (including, but not limited to,
the smallest known factor (noted if it isn't))
My data contains some prime exponents with as many as eight known
prime factors.
2) Largest potential factor attempted
I have this as well, but there are also some gaps in the trial
factoring efforts to date, which I also keep track of and try to
close.
I ask that the two items are human-readable at the
very least.
The format I use is described in the mersfmt.txt file; it is human
readable, being primarily alphanumeric plus parentheses and colon (:).
Conversion to just about any other printable format is easy; UNIX has
lots of tools that allow this sort of text manipulation.
I've pulled a couple of files off mersenne.org
(FACTORS.ZIP and NOFACTOR.ZIP) as well as off
Alex Kruppa's page. While the files appear complete
as far as I can tell, they only cover the ranges
of p between 11 - 9,999,991 and 33,219,281 - 35,999,993.
Correct. George has still not asked me for my data for exponents
above 10 million, but it's probably almost as easy to retest as to
have me send (my data isn't very deep for the exponents above 21
million or so), and makes for a good double check.
They also don't cover *all* known factors!
Correct; since GIMPS is mainly looking for Mersenne primes, Prime95
stops at the smallest factor (which is not always the first factor it
finds for an exponent because of the 16 pass approach in the sieving
code).
Any and all information on the ranges between 10M - 33.22M and
above 36M is greatly appreciated, as well as any known factors not
listed in the files I've pulled.
My prime exponent data for all ranges is now about 111 MB; this
includes all known factors, each exponent's largest attempted trial
factor, and all the ECM and P-1 effort (but no P-1 save files). The
gaps data is another 9MB, and the P-1 save files, mostly from
Factor98, are about another 110 MB. All but the P-1 save files use
the format described in:
http://www.garlic.com/~wedgingt/mersfmt.txt
... which is human readable and accepted by the mers package programs.
The P-1 save files are understood by the mers package's extract enough
to print most everything but the "residue" itself, including the beta
release's extract understanding the new P-1 save file format of George
Woltman's Prime95 v19. Extract's understanding of the P-1 save file
formats will be extended, when I get around to it, to converting from
one P-1 format to another.
Conrad Curry writes:
Will Edgington maintains this information, but it may be
hundreds of megabytes in size. If a website, such as
Entropia, has the space it will be useful to make this database
available (in many small compressed files) so that others may
use it.
Yes, but the first problem is that my 56Kb modem is in the way.:(
But I would be willing to upload it a range at a time over a month or
so, going back to the start to update ranges that have changed since
their last upload, if someone out there has enough web disk space
for it.
And what GIMPS needs, the list of prime exponents with some data but
no known factors, is still quite small, especially in the binary
DATABASE format (which extract can print in the mersfmt.txt format);
that DATABASE file for all prime exponents with data but no factors is
only 2MB presently. It is produced by the contract program during my
updates and put in the mersdata.{zip,tgz,tar.gz} file.
Eric Hahn writes:
If no information is known where p100M, then what can I do??
I have some data for exponents over 2^31. The smallest prime exponent
with no data is only 21556027 presently (though I increase it some
with every update), however, and most of the data is below that.
Also, generating new data for a given prime exponent under about 2^60
(if your machine has an eight byte integer type available in C) or so
is easy using mersfacgmp; all it takes is CPU time.
Will
http://www.garlic.com/~wedgingt/mersenne.html
mers.tgz
mers.tar.gz
mers.zip
mersfmt.txt
mersdata.tgz
mersdata.tar.gz
mersdata.zip
_
Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: Re: Mlucas 2.7x on SPARC
The SPARC binary Alex Kruppa sent me of Mlucas 2.7x is at my ftp site: ftp://209.133.33.182/pub/mayer/README ftp://209.133.33.182/pub/mayer/bin/SPARC/Mlucas_2.7x.exe.gz My browser auro-uncompressed the .exe file during transmission and I had to rezip it, so if you get any errors in uncompressing, please try grabbing the original: www.informatik.tu-muenchen.de/~kruppa/Mlucas2.7x.gz I don't even know if the above runs on a machine that doesn't have an f90 compiler installed (i.e. whether the code needs any f90-specific RTL files)- I don't think it does, but anyone with an f90-less SPARC can easily find out. Remember, this a beta - please send me your comments/suggestions/timings /bug reports without delay! Enjoy, Ernst p.s.: visitors to Alex's website should check his class schedule (Stundenplan)- one of his professors has a name that is vaguely familiar. I know I've been busy, but I didn't realize I've been THAT busy, nor that I'd grown a beard. Dementia sets in... _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: Re: and, from WAY out in left field...
Hi, Ian: Frankly I can't see any point updating to V19 when I am already testing a factor of 9Meg+...especially with a Cyrix 333 Now you have some idea how the (non-Intel) Unix folks have felt for much of the past 3-4 years...and those are often US$5000-2 machines. As with all distributed efforts, we all contribute what we can. It's not a contest, except perhaps amongst us programmers, in terms of pushing each other to continually improve our codes. Sorry, I am bitter and can't afford a 550 Pentium. Hopefully soon - here prices have dropped below 1000 $US for 500MHz systems- you can get a 300-400MHz PII virtually for free if you're willing to pay $20/month for 36 months of unlimited Internet access. You should try buying online, e.g. at www.valueamerica.com or some such store. I update regularly but no time is credited... You usually don't get credit until an exponent or several factoring assignments have completed, and at the moment the forner is taking months even on decent hardware. Also, manual tests (like I do on my Unix boxes) don't get cerdited on the Entropia top producers pages, but do on George's master list. On the other hand, if you have been doing stuff for many months and are connected to PrimeNet yet see no credit, contact Scott [EMAIL PROTECTED]. How do I know that the exponent I am testing has not already run to conclusion.? PrimeNet (so far as I know - I didn't write the networking software) doesn't hand out duplicate assignments unless it doesn't "hear" from machine X for a long time - George is interested in the large-scale progress of the search (which would be impeded by unnecessary work duplication) more than finishing off all exponents below so-and-so-many millions by Y2K. Chin up - the cheap Pentia are out there, you just to have find them - perhaps prices are higher in the UK, but the Internet makes that a non-issue, I think. Cheers, Ernst _ Unsubscribe list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
