Mersenne Digest Friday, May 21 1999 Volume 01 : Number 562 ---------------------------------------------------------------------- Date: Tue, 18 May 1999 18:47:48 -0400 From: Jud McCranie <[EMAIL PROTECTED]> Subject: RE: Mersenne: Monitor Flicker on Dell P-II 450 MHz At 02:52 PM 5/18/99 -0600, Aaron Blosser wrote: >So basically, it's just a poorly designed box. That's what you get for >buying Dell, but that's just my opinion :-) I've got 3 Dells, and I've run prime95 on at least two of them and I never had the problem. ________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm ------------------------------ Date: Tue, 18 May 1999 16:19:14 -0700 From: Joe Decker <[EMAIL PROTECTED]> Subject: Re: Mersenne: Monitor Flicker on Dell P-II 450 MHz Aaron Blosser wrote: > If the problem were pervasive in many applications, I'd waste no time in > calling Dell and asking for a fix. As it is, if only FPU intensive apps > cause the problem, they probably wouldn't care. It's not pervasive, and even other floating-point-intensive ops don't trigger the problem, to my eyes, as badly as prime95. But I do see the effect a bit in other apps. I doubt I would have noticed it in anything but prime95, however. > If it's radiated interference, maybe some good copper braiding > around the CPU would help, tied to ground. Or around the graphics > circuitry. But again, if the problem is interference on the wiring, you're > SOL. Send 'em back and get Compaqs! :-) ...or a separate video card. - --Joe ________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm ------------------------------ Date: Tue, 18 May 1999 16:23:39 -0700 From: Joe Decker <[EMAIL PROTECTED]> Subject: Re: Mersenne: Monitor Flicker on Dell P-II 450 MHz "Blosser, Jeremy" wrote: > Actually, I went and looked at the newsgroups and a few people posted about > an apparently bad batch of 1226H monitors, and suggest sending them back and > getting the P-990's instead. So if you have this monitor, perhaps that is > the problem there... Don't have that one, but I tested several different makers of monitor ... it's pretty clear that one component of the issue is the integrated video. - --Joe ________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm ------------------------------ Date: Tue, 18 May 1999 16:44:23 -0700 From: Joe Decker <[EMAIL PROTECTED]> Subject: Re: Mersenne: Monitor Flicker on Dell P-II 450 MHz Jud McCranie wrote: > > At 02:52 PM 5/18/99 -0600, Aaron Blosser wrote: > > >So basically, it's just a poorly designed box. That's what you get for > >buying Dell, but that's just my opinion :-) > > I've got 3 Dells, and I've run prime95 on at least two of them and I never had > the problem. Same here. I've got piles of Dells here, it's only a particular model or two that's problematic. - --joe ________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm ------------------------------ Date: Tue, 18 May 1999 20:25:49 -0400 From: Chris Nash <[EMAIL PROTECTED]> Subject: Re: Mersenne: Repeating LL remainders Just a quick note to thank Peter for his wonderful illustration of the "repeating LL test remainders" question, with what I hope was a somewhat surprising result! > That is, S(32341) == S(1) mod M23. > This is far more than 23 LL steps before the sequence repeats. > EXERCISE: Repeat this analysis modulo M11 = 23 * 89. > Find the period modulo M29 = 233 * 1103 * 2089, after getting > the individual periods for each prime factor. *smiles* I will not pre-empt the result for anyone who wants to calculate these. The important observation is to look at each factor in turn just as Peter suggests. One can almost work in reverse as well. What we see in a (Mersenne number) Lucas-Lehmer test really is a very small sample of the sequence (2+sqrt(3))^n. If a cycle were detectable from this small sample, then all the factors of the number under test must satisfy some very stringent, perhaps intractable conditions. As Brian Beesley points out, I was guilty of a lot of guesswork, and didn't go into details of the calculation of the period of the L-sequence. Hopefully Peter's excellent examples show that the chances of the L-sequence period being spotted in a much briefer S-sequence are very small indeed. Chris ________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm ------------------------------ Date: Tue, 18 May 1999 18:42:19 -0700 From: Todd Sauke <[EMAIL PROTECTED]> Subject: Re: Mersenne: Any statistics majors out there? George, Thanks for sending me the raw data for the round-off error distribution. The empirical data fit the cumulative distribution function (introduced by Brian Beesley) reasonably well with the value "N" of several hundred to a thousand, which matches my understanding of about how many round-offs each of your points is the maximum of, so that seems to bode well. Both the theoretical curve and your empirical data (when plotted as one minus the cumulative distribution function (on a log scale) versus round off error) are nearly linear once you get past the "breaking point" (essentially the peak of your distribution). This means that you can use a VERY EASY, yet decent, approximation to estimate the probability you seek, i.e. that there will be no roundoff error greater than 0.5 in an LL test. If you run a test of 10,000 iterations and tabulate the histogram of maximum errors as in your raw data, the probability you seek is ~: P * 10^(-3 * (0.5 - A) / (B - A)) where: P = the Mersenne exponent under test A = the peak of the distribution (the most frequent maximum round off error) B = the TENTH largest round off error of the 10,000 iterations (i.e. where 1 minus the cumulative probability distribution is ~ 10^-3) This estimate would appear to be appropriately conservative, since the deviation from linearity is such that the real curve bends down to lower probability than this linear estimate. For your specific examples: P = 1,345,000 A = 0.177 B = 0.245 Estimated probability of roundoff error for entire LL test ~ 8 E-9 And P = 1,360,000 A = 0.250 B = 0.375 Estimated probability of roundoff error for entire LL test = 1.4 The "probability" being greater than one comes because the "small probability" condition for the estimate is violated [ 1 - (1 - e)^ P ~ P * e only for e << 1/P ] We don't care about this regime, the error probability is far too great. By the way, I bet that you could do interpolation/extrapolation (in Log space) to determine the "cutoff" value without having to run the 10,000 iteration test for ALL candidates. Log10 (Prob(1,345,000)) ~ -8 Log10 (Prob(1,600,000)) ~ 0 So for example I bet that Probability of roundoff error for entire LL test for P = 1,472,500 (halfway between exponents) is ~ 10-4 (logarithmically halfway between probabilities). You probably already have the raw data to test this out. I hope this can let you SIMPLY estimate the relevant probabilities with some degree of confidence in the estimates (pseudo rigorous). Sincerely, Todd Sauke ps. To avoid the "small probability" requirement in the probability estimate you could just use the equation [ 1 - (1 - 10^(-3 * (0.5 - A) / (B - - A)))^ P ] but DON'T use this if you want to do the logarithmic interpolation using any numbers that come close to (or over) 1. The "incorrect" estimate is what works best for the logarithmic interpolation! TS >George, > >Given the uncertainty about the actual probability distribution function >involved it seems that the best way to estimate the probability of having >no roundoff greater than 0.5 in one iteration is to simply plot one minus >your empirical cumulative distribution function (on a log scale) versus >round off error on a scale that goes out to 0.5, and extrapolate by >"eyeball" to see where the curve would hit 0.5 and if it would be below >1e-10 or 1e-15 or whatever. Wherever the curve hits (or appears it would >hit) 0.5, times the number of needed LL iterations (p), gives an empirical >estimate of the probability that there will be no roundoff greater than 0.5 >(for small values of probability, of course). > >It is likely that some (few?) individual people who are "into" this could >use the raw Excel data numbers, not just the plots you pointed us to (which >I still can't make my computer see.) I would appreciate it if you could >ship me one or two files with probability histograms (or occurrance density >or whatever) versus roundoff value that could be loaded into Excel 4.0 for >Mac. > >It might be interesting to see if the shape of this log-lin plot follows >the one given by the cumulative distribution function a-la Brian Beesley. >This function seems to have one degree of freedom, the number of rounded >off values of which the maximum one gives your function, which in his >example he chose to be 100. You probably know from the code what that >number should be. (Another degree of freedom is the underlying uncertainty >or the "scaling factor" for the x axis.) You might also know from the code >what the "underlying" sigma should be under the assumption that it is >something like (sigma0 * SquareRoot(n)) where n is the number of roundings >that occur in the cumulative calculation and sigma0 is the typical >"elementary" round-off error (scaled properly to be in the same units as >the 0.5 critical roundoff limit). If this is not available a-priori from >the code, it would still be interesting to estimate it by finding the best >fit to your empirical cumulative distribution function. If the resulting >smooth cumulative distribution function is a good match to the empirical >one it could serve as a guide for better extrapolation (or instead of the >extrapolation). If it is not a good match it would serve as a "warning" >that there may be "funny" things going on with the errors (particularly >worrysome if the "tail" is trending up, implying larger errors are more >likely than indicated by theory). > >Todd Sauke >________________________________________________________________ >Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm ________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm ------------------------------ Date: Wed, 19 May 1999 11:16:06 +0100 From: Robin Stevens <[EMAIL PROTECTED]> Subject: Mersenne: HTML posts On Tue, May 18, 1999 at 03:43:06PM -0700, Mersenne Digest wrote: > - --------------2F0C58BF3B6CAD96679EFF20 > Content-Type: text/plain; charset=us-ascii > Content-Transfer-Encoding: 7bit [snip post in nice ascii text] > - --------------2F0C58BF3B6CAD96679EFF20 > Content-Type: text/html; charset=us-ascii > Content-Transfer-Encoding: 7bit > > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> > <HTML> [snip repeat of the above but in HTML] Apologies for the off-topic post, but could I please request that people posting to this list do so in plain text format and not HTML? There have been several such posts of late. It's incredibly irritating to those with less advanced mail programs, or to those who read the digest. Please pay a visit to http://www.rootsweb.com/rootsweb/listowners/html-off.htm if you don't know how to configure your mail client appropriately. - -- - -------------------- 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 ________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm ------------------------------ Date: Wed, 19 May 1999 23:37:10 -0700 (PDT) From: [EMAIL PROTECTED] Subject: Re: Mersenne: HTML posts Hey, I have an idea. Since Luke adds the nice little sig at the bottom of each message, can he "fix" the Content-Type: text/html line if it shows up in an e-mail??? Seems like a simple matter of changing the "html" to "text". If we want to really get crazy a simple perl script could strip out the HTML tags while still retaining the proper formatting as well as notify the offender of his mistake. Of course, we could simply bounce the message back to the offender and make them fix it... - -Chuck On Wed, 19 May 1999, Robin Stevens wrote: > On Tue, May 18, 1999 at 03:43:06PM -0700, Mersenne Digest wrote: > > - --------------2F0C58BF3B6CAD96679EFF20 > > Content-Type: text/plain; charset=us-ascii > > Content-Transfer-Encoding: 7bit > [snip post in nice ascii text] > > > - --------------2F0C58BF3B6CAD96679EFF20 > > Content-Type: text/html; charset=us-ascii > > Content-Transfer-Encoding: 7bit > > > > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> > > <HTML> > [snip repeat of the above but in HTML] > > Apologies for the off-topic post, but could I please request that people > posting to this list do so in plain text format and not HTML? There have > been several such posts of late. It's incredibly irritating to those with > less advanced mail programs, or to those who read the digest. > > Please pay a visit to > http://www.rootsweb.com/rootsweb/listowners/html-off.htm > if you don't know how to configure your mail client appropriately. > > -- > -------------------- 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 > ________________________________________________________________ > Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ : WWW: http://www.silverlink.net/poke : : E-Mail: [EMAIL PROTECTED] : ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ : Ask Mike! Aviation's response to Dear : : Abby. http://www.avstarair.com : ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm ------------------------------ Date: Thu, 20 May 1999 08:13:59 -0700 From: "John R Pierce" <[EMAIL PROTECTED]> Subject: Re: Mersenne: HTML posts > Hey, I have an idea. Since Luke adds the nice little sig at the bottom of > each message, can he "fix" the Content-Type: text/html line if it shows up > in an e-mail??? Seems like a simple matter of changing the "html" to > "text". If we want to really get crazy a simple perl script could strip > out the HTML tags while still retaining the proper formatting as well as > notify the offender of his mistake. Of course, we could simply bounce the > message back to the offender and make them fix it... The majordomo based list server I use for another mail list bounces HTML back to the author. I dunno what the owner of that server did to hack it though. The parsing of mime is fairly complex and messy. ________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm ------------------------------ Date: Thu, 20 May 1999 10:07:38 -0700 From: Will Edgington <[EMAIL PROTECTED]> Subject: Mersenne: factorization Tony Forbes writes: I know it's a bit feeble the usual standards for ECM factorization, but Seems to me that "feeble" certainly doesn't include factors that are new! Besides, I'm doing some work on 11-digit factors.:) I just found this 36-digit factor of 2^2203+1 : 848425589476255002200418022118728331 Great! Thus 2^2203+1 = 3 * 13219 * 208613913329 * 743372438374143806443 * 282324958084937237369 * 848425589476255002200418022118728331 * C571 I apologise if this is not new or not interesting. New factors are always interesting, at least to me. And "new" is relative; I don't always have time to update my web pages each week. I am still trying to find numbers n > 1000 where gcd(n, 30) = 1 and 2^n- 1 and 2^n+1 are completely factorized. Like 2203 would be once the C571 part has been factorized (2^2203-1 is prime). The only ones I know are 1121 and 1141. Anyone know of any more? There may be more in my data; check: http://www.garlic.com/~wedgingt/factoredM.txt Note that 2^n - 1 is listed there with n as the exponent; 2^n + 1 is listed there with 2*n as the exponent, since: 2^(2*n) - 1 = (2^n - 1)*(2^n + 1) by the difference of squares factoring method. E.g., take the case of 2^2203 + 1; it's listed under 'M( 4406 )' but does not include the first factor listed above (3) since that is also a factor of a smaller Mersenne number (M(2)). (If this wasn't done, 3 would be listed next to all even exponents, 7 next to all exponents that are multiples of 3, 5 next to all that are multiples of 4, etc; see ecm3.c of the mers package for how this is done). Will P.S. Here's the most recent run of a new program of mine: + 1strs8gmp -r617 32768 13000000069 13100000000 M( 20163 )C: 13001425009 M( 24603 )C: 13013067967 M( 28795 )C: 13014015431 M( 30644 )C: 13015272901 M( 19130 )C: 13016377211 M( 16105 )C: 13032166001 M( 10997 )C: 13032852617 M( 13762 )C: 13034540681 M( 20190 )C: 13044597481 M( 11660 )C: 13051970801 M( 17388 )C: 13053675853 M( 5358 )C: 13062782569 M( 7160 )C: 13070164721 M( 13414 )C: 13078100027 M( 13428 )C: 13098436597 M( 7292 )C: 13098758149 It printed all factors (from 13 to 13.1 billion) that are not already in my data of all Mersenne numbers between the two arguments to -r (617 and 2^15, here). It took about 6 hours this morning on my new P233MMX CPU (my P200's mainboard appears to have fried Sunday night in a power outage & surge; sorry if email to me bounced in the mean time. I believe that no data was lost, though I still have some bad blocks to fix/redirect). Note that it would run at the same speed if the limit on the exponent were removed, but it would be full of data for composite exponents up to the size of the factor. ________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm ------------------------------ Date: Thu, 20 May 1999 13:25:18 -0400 From: "Pierre Abbat" <[EMAIL PROTECTED]> Subject: Re: Mersenne: HTML posts The type you're looking for is not text/html but multipart/alternative. If it's multipart/mixed, that means there's an attachment. If the MIME type of the message were text/html, that would mean that it is just an HTML message with no text alternative. phma ________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm ------------------------------ Date: Thu, 20 May 1999 14:57:11 -0700 From: Gordon Irlam <[EMAIL PROTECTED]> Subject: Re: Mersenne: HTML posts BTW, if someone wants to solve this problem, the best way to go about it would be to have the necessary changes integrated back into the baseline release of majordomo. I could then pick up these changes. This way the changes would be stable, and not break as a result of an upgrade to a future version of majordomo. It would also have the big advantage of solving this problem for everyone in the world, rather than just this one list. thanks, gordoni (list admin) ________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm ------------------------------ Date: Fri, 21 May 1999 13:26:13 -0600 From: "Blosser, Jeremy" <[EMAIL PROTECTED]> Subject: Mersenne: Odd observation So I have a K6-233 at home, no overclocking nothing. And have it double checking primes and the particular prime it is working on, it gets a consistent .268s/iteration (w/ recache). I verified this over some 3-4 days... Then I have a case fan break on me, so I go to the good ole MicroCenter on the way home from work to pick up a new one. While there, I also pick up a peltier cooler (because they had one). I put in my new case fan and peltier cooler, start up my computer and head off to work and all... no changes made to software or anything. So, I come home and look at Prime95 and while before it was getting .268s/iteration it is now getting .247s/iteration (consistently)... While not seemingly much, that shaves some 37000 seconds off, or 10 hrs or so off the full factoring time... (P=1843147 or something) Which brings me to my odd observation... Could the cooler CPU temp speed up operations by that much? Or am I going insane? I know that the physics of it says it should be a *little* bit faster, but .02s/iteration faster? Someone please explain this to me. :) Jeremy ________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm ------------------------------ End of Mersenne Digest V1 #562 ******************************
