Mersenne: Various ways of changing horses in mid-stream
I have a P4/1300 which doesn't have an Internet connection. So, to get work units to and from it, I copy the whole prime95 directory to my K6/333 laptop which *does* have an Internet connection, and then run prime95.exe to get it to talk to the server. The K6/333 is something like a factor 24 slower than the P4/1300, and is often turned off, so I don't run any prime95 computations on it at all. The problem is, the P4 code in prime95.exe obviously won't work on the laptop. So when I run on the laptop, it rewrites local.ini to indicate that it's a Pentium [though it _doesn't_ change the MHz figure], and then collects work units as if it were a Pentium/1300. All I can think of is telling the K6/333 that it's actually a K6/8000, waiting for it to contact the server and collect work sized for a K6/8000, which the P4 should be able to run through at the correct rate, and then copying the worktodo.ini file obtained by this subterfuge to the P4 to get the work done. This seems somehow inelegant, particularly in that my account report now says that I have an 8000MHz K6 machine called Tom_s_P4 ... what's the right way of doing it? As another point, I have five Athlon/850 machines in the computer lab at college; so I've installed mprime in five separate directories on the shared file space, and let it allocate its own computer names. Yesterday I got fed up with trying to remember that CA1C7B916 was actually the machine called ouzo, so I stopped mprime on each machine, edited local.ini to change the name, and restarted mprime. Has this confused everything horribly? _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: Purpose of the self-test; also, aren't P4s fast!
I've just collected the beta of version 21, to run on my P4 at home. When I run it on my K62/333 laptop (which I was using as a portable disc having downloaded the beta at college), the self-test tries to test M5242881 with a 256k FFT, gives an excess-roundoff-error message and dies; this is presumably a bug. I did set the processor type to K6. When I run it on the P4, the self-test checks a set of thirty or so exponents with a 320k FFT length, and then does it again, and again, until it's run a total of 306 tests. This surprised me slightly; I was expecting it to exercise all the FFT lengths with random exponents to check for edge-conditions in the new P4 code. Is the self-test in fact just to check that there's not something in the CPU which goes glitchy when running flat-out SSE2 code for hours on end? The P4's PSU fan seems to step up a gear when I've been running Prime95 for a few hours, though the CPU temperature reported by Intel Active Monitor on my D850GB board doesn't go about 46C. I suspect the P4 probably runs too hot for it to be possible to build a really quiet solution, but does anyone have suggestions? In its current state I'd get no sleep if I left the machine running overnight, so I'll probably be running Prime95 only if I remember to set it going when I wake up. 33M ticks per iteration for M5171311, which is 25.8 milliseconds on this 1300MHz machine; so one double-check in that range every 36 hours. That's about a factor six faster than the P2/350 I just sold, and I recall that machine as having been at least four times faster than the P90 I had when I started running Prime95 ... I'll have done noticeably more calculation by the end of next month than that P90 did during its lifetime. Tom _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
Mersenne: Why do I get only double-checks
I'm using a P3-500E box at college to run mprime. The relevant lines of the local.ini look like LastEndDatesSent=967023734 RollingStartTime=968950008 RollingAverage=4000 CPUType=1 CPUSpeed=500 CPUHours=24 How come I get given only double-checks to do? I don't mind too much -- the machine kills off a double-check in ten days -- but I'd be slightly surprised if the frontier of 'obsolete; use for double-checks only' had reached this one-year-old box yet. That Rolling Average figure looks kind of high, too. Tom _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.exu.ilstu.edu/mersenne/faq-mers.txt
Mersenne: Utterly weird behaviour of mprime
Hi, I just installed mprime v20 for Linux on the P3 box I use (perhaps it's relevant here that the filesystem mprime is on is NFS-mounted from a server somewhere completely different); and it's gone completely mad. When I installed it, I was about half-way through completing M10540451. First, it stopped working on M10540451, and did 21059 iterations of M10725553. *Then* it conducted a complete P1 factorisation of M10725553, finding a factor. Rather than going back to M10540451, it collected M5290331, performed a P-1 test on it, and ran 1638401 LL iterations, before stopping work on that and starting a P-1 factorisation of M9728591. This is the same process running constantly, so it's not a matter of stopping and restarting it at peculiar times. I'm left with qA540451, pA540451, q5290331, p5290331 and m9728591 as checkpoint files; my worktodo.ini reads DoubleCheck=5290331,63,1 Test=9728591,64,0 I can understand starting the P-1 factorisation before finishing the double-check, but I don't see where M10540451 has gone, or why the computer did 21059 LL iterations on 10725553 before doing the factorisation. Tom _ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.exu.ilstu.edu/mersenne/faq-mers.txt
Mersenne: Re: Mersenne Digest V1 #495
>From: "Alexey Guzeev" <[EMAIL PROTECTED]> >Date: Tue, 12 Jan 99 08:30:42 -0500 >Subject: Mersenne: Factoring > > Ok, George's programs looks for only for factors of M(n) in form >1) 2kn+1 > that's clear why >2) 1,7,17,23,31,41,47,49,71,73,79,89,97,103,113,or 119 modulo 120 > but this is not. Why factors 120k+13 are not considered? Or 120k+19? Why only those 16 reminders of >~30 primes below 120? Because a separate theorem tells us that factors of Mersenne primes must be 1 or 7 modulo 8 (because 2 must be a quadratic residue. The argument is simple, but I learnt it carefully for Finals and have now forgotten it).
Mersenne: entropia.com logs
I'm now *very* confused about the logs at entropia.com. I keep my own log of the exponents I've searched - it's got 30 entries at the moment. I've been running basically full-time on Primenet since November 1997 on a P2/233, becoming a P2/350 in November '98. However, the records have me as testing 18 exponents, and having accumulated only about 1.3 CPU-years in about 1.3 real years. In *** Exponents test completed (cleared) since last master database synchronization *** there are 12 more exponents listed - but it looks as if the machine is thinking I ran double-checks on nine very small exponents which I finished running before 1998 even started, and the 'days run' figures on the exponents allocated to me look meaningless (they're measured from when the exponent was given me, rather than when I started running it). I certainly have *not* been doing double-checking! Is there any way I can get a list of the exponents entropia.com thinks I've searched; I think I've searched (for the first time) 2842529, 2842531, 2842573, 2842589, 2842597, 2842603, 2842649, 2842691, 2842739, 3903373, 3712949, 3738869, 3739103, 3739129, 3742961, 3959587, 4326859, 3745361, 4350889, 4495867, 4494947, 4568089, 4119007, 4876969, 5205749, 5086493, 5086507, 5086517, 5086603, 5297879. Really good would be to get a list of the exponents I searched before entropia.com came along, but I guess that's impractical (unless Woltman has a file result-submissions in which he can grep for me). On a second note, I can't quite see how I can get Prime95 to do ECM factorisations - I've read the source code, even, but I can't quite see how to get the password dialogue in which to put in the password to enable ECM testing. I like the idea of running ECM, particularly since it means I can actually make some discoveries with *numbers* in, rather than just 'Mersenne numbers 2842529, ..., 5297879 are composite'. Tom Womack, who thinks he should probably be above 993rd in the list.
Mersenne: All ranges handed out
All the ranges have now been handed out for the s253 problem - I've been overwhelmed by the response, though probably the success of GIMPS should have made me expect it. I'll wait for the results to come in before deciding if it's worth launching a larger search. Thanks very much for helping, everybody! Tom Womack
Mersenne: Not broken any more! Please continue
I've fixed the code - it took about three minutes to find the two bugs, and then about three hours to run enough test cases to convince be that there were only two bugs. [Laurent's idea with return(u-v) failed since u and v are of type int64 and the qsort routine must return an integer, and I'd got the program flow wrong through assuming the compiler would understand the indenting rather than the braces] Please download the new source or executables. If you haven't been handed a range yet, please *rerun the 's253 TEST' command and mail me the result*, and I'll hand you one. If you started the project with the buggy code (I hope only Paul Leyland was hit by this), just reissue the 's253 INIT ' command and start again. If you had been running with the original slow code for a while, have a look at your s253.results file in a text editor. It consists of lots of lines of the shape counter : time x y z [maybe more sets of x y z] At some point near the end, you will notice that the 'time' field goes down substantially and the sets of x y z vanish. Note the value of the counter at the point the time goes down - *this may be before the first x y z vanishes*. For example, if your file ends 9936 : 659000 0 0 21538 9937 : 705020 0 0 23561 9938 : 134070 0 0 33819 9939 : 137260 then the relevant value is 9938. Delete all the lines from that counter value to the end of the file, inclusive, and issue 's253 INIT ', where is the end of your original range. Then issue 's253 CONT' or 'start /m s253 CONT' or 'nice 19 ./s253 CONT', or whatever command your operating system prefers, and carry on crunching ... Sorry to muck you around; I'd incorporated a test case which I hoped would stop me doing anything this stupid, but there was a bug in the test routine. I had assumed the program would return the right number, albeit possibly of wrong answers, so the test as coded returned success if the answers returned were a subset (including an empty subset) of the correct ones. Tom
Mersenne: Ah - forgot the important bit.
The new code is six times as fast as the old one. Tom
Mersenne: An Upgrade to the 27,84,110,133,144 project ...
[this message is going out to the Mersenne mailing list and the current volunteers; ignore paragraphs which don't seem relevant to you] I'd like to beg pardon for particularly gross stupidity in the matter of optimisation. After prodding from Joe Decker, I realised my code was being very inefficient in using bsearch every time; now, it uses a table to look up the top 17 bits of a^5+b^5+c^5, which throws out a lot of values immediately and usually means a linear search is more efficient than bsearch over the remaining values. Laurent Desnogues pointed out that I could just return (u-v) from the qsort compare routine rather than doing comparisons, which provided a further 15% improvement because the MS C compiler produces rather inefficient code for 64-bit comparisons; I'm not sure how this will affect glibc systems. I've updated the Web page, though I don't have a Linux box with egcs-1.1.1 available and it would be good if someone with one of those compiled the source with i586 and i686 optimisations (statically linked), and mailed me the result. Just download the source or executable, and it will chew through the rest of your range in (hopefully) under 24 hours. If you've not been issued a range yet, please run 's253 TEST' and I'll issue you a range. The project will be completed by about Saturday at this rate; I'm currently working on a version looking over a much larger range, which would keep distributed.net occupied for a few days. I've received a few partial results from people - don't be too amazed if the .results file contains non-trivial results [ones not of the form 0 0 x], the code will pick up every multiple of every rearrangement of the [27 84 110 133 144] solution, and this is deliberate so I can check easily that it hasn't missed anything. Tom
Mersenne: Looking beyond 27^5+84^5+110^5+133^5=144^5
I've written some software to look for further solutions to the infamous problem one of whose solutions is above. It's available, in source and five sorts of executable, from http://users.ox.ac.uk/~mert0236/s253/ To do a search up to 2^15 will take approximately one P2/350-year; however, the problem splits up trivially among lots of computers. If anyone here is prepared to contribute idle cycles to this problem, please read the web page and follow the instructions on it. There's enough hardware running GIMPS to solve the problem in an hour, so it'd be great if I could get even 1% of that to help. I'm afraid range allocation is manual - the problem didn't seem big enough to make it worth writing automatic range allocation code. Yours sincerely, Tom Womack
Mersenne: Goldbach's Conjecture
Ah, this is more fun than complaints about network administration ... Goldbach's Conjecture states that every even number greater than 4 is the sum of two primes. It hasn't been proved yet; the closest we've got is a result by Chen using sieve theory which shows that every sufficiently large even number can be written as the sum of a prime and a number with at most two prime factors. If you define r(n) as the number of ways n can be written as a sum of two primes, we have r(250) = 14 [since 250 = 83 + 167 = 71 + 179 = 59 + 191 = 53 + 197 = 23 + 227 = 17 + 233 = 11 + 239, and we count each of those twice]; as far as I know r(n) is very rarely 2, so Joel's comment about uniqueness is unfortunately false. We'd expect Goldbach's Conjecture to be true, since the probability of a number around N being prime is roughly 1/log N, so (assuming all sorts of false theorems about independence) the probability of both k and N-k being prime is roughly 1/(log N)^2. So the probability of them *never* being both prime is roughly (1-1/(log N)^2)^(N/2), since there are N/2 ways of picking k and N-k. Now, this tends to zero very quickly with N. In fact, we can do better; there are roughly x/log x primes less than x, and roughly 1/log x of those will have x-p also prime, so we expect R(x) = x/(log x)^2. As far as my tests have run, we never have R(x) < x/(log x)^2, let alone R(x) = 0 which is what a counterexample to the Goldbach Conjecture would entail. I've ran a test for N<2^26, which took a night on a P2/233, and produced the data graphed in http://users.ox.ac.uk/~mert0236/maths/goldbach.gif and http://users.ox.ac.uk/~mert0236/maths/goldbach[2..4].gif. What I'm plotting there is the probability density function of (R(x) log(x)^2)/x; you will notice the pretty fractal structure, which I am at the moment utterly unable to explain. Nicolau wrote : > Given N, let f1(N) be the number of primes of the form 4n+1 which > are smaller than N, and f3(N) be the number of primes of the form > 4n+3 which are smaller than N. Thus, f1(10) = 1 and f3(10) = 2. > Is it true that f1(N) <= f3(N) for all N? > >The answer is no, but I challenge you to find a counter-example. The computationally harder problem is to have f1(N) being primes of form 3n+1 and f2(N) being primes of form 3n+2; f2 wins up to N=608981813029. For your f1 and f3, f1(N)=f3(N) for N around 26932, around 615868, around 12311564 ... It's probably unwise to make large computational challenges on a list whose members almost by definition are interested in maths and have fast computers. Tom
Mersenne: Re: Mersenne Digest V1 #463
[sorry, replying to digests is probably unfriendly, but I can't face hordes of email. Do people mind if I just reply to interesting messages from the digest two-daily or so?] >From: "Pete" <[EMAIL PROTECTED]> >Date: Tue, 10 Nov 1998 18:26:53 - >Subject: Re: Mersenne: windows 98/FAT32 > >Thanks for all the suggestions. >I converted back to FAT16 using Quarterdeck 'Partition-It' and the HDD now >powers down again. >I have set up prime95 to write to disk every 300 minutes. Ah. I'm fairly sure that wasn't necessary, simply because the machine here will power down its hard disc quite happily (though I've disabled it because of the prime95 writes) even under FAT32. >-- >From: George Woltman <[EMAIL PROTECTED]> >Date: Tue, 10 Nov 1998 13:38:18 -0500 >Subject: Re: Mersenne: New features of Prime95 (v. 17) output >The fourth value is a count of "SUM(INPUTS) != SUM(OUTPUTS)" messages. Should I assume that, if I've received one of these messages, my run is clearly invalid and should be restarted, or has the computer just gone back to a previous save file or to the previous value and carried on? [I think there's still some MMX code around which doesn't clear up properly after itself ... why didn't Intel mandate saving and restoring the MMX registers on context switch?] >-- >From: Blake Stacey <[EMAIL PROTECTED]> >Date: Wed, 11 Nov 1998 10:49:20 -0600 >Subject: Mersenne: Re: Thoughts > >I agree that modeling nuclear detonations take a lot of computing >power. However, I'm pretty sure that this couldn't be done on a distributed >parallelistic basis. (Is that even a word--parallelistic?) >For the life of me, I can't figure out how to distribute the >mathematics. It seems that each region of the space where the explosion >is happening needs constant information from most of the others (or >maybe just those directly adjacent). You don't need information from everywhere, just from adjacent regions - so you partition the space into 48 regions, one per 128-processor SGI supercomputer (if Blue Pacific is the one I'm thinking of, otherwise s/SGI/IBM), and at each tick you need only pass the boundary data across the insanely fast interconnect. Remember, the interconnects in something like Blue Pacific are three orders of magnitude faster than the Internet bandwidth, and at least one order of magnitude more than the total trans-Atlantic bandwidth; I'd not be startled if a single run on Blue Pacific involved more communication than the Internet to date. >-- > >From: Yuri Sorkin <[EMAIL PROTECTED]> >Date: Wed, 11 Nov 1998 22:48:37 -0800 (PST) >Subject: Mersenne: What computer is OK today? > >I participated in GIMPS from the very beginning, yet trying to join it with >386-SX. And now I see that my P5-166 (SDRAM, MMX, Intel) doesn't get >from Primenet anything for LL-test quite awhile. Since I'm going to buy a >new desktop soon and consider its suitability for GIMPS to be a certain >indicator of satisfactorily performance, I wonder what computers get >exponents for a test now? Four months back? I'm being fed exponents to LL-test on a P2/350 - I'd recommend you get a BX motherboard and a large pile of SDRAM, start with a P2/350 or even an overclocked Celeron if you want to live dangerously, and expect to upgrade when Intel give away Katmais in cornflake packets. Tom
