Mersenne Digest Saturday, May 6 2000 Volume 01 : Number 728
----------------------------------------------------------------------
Date: Wed, 03 May 2000 14:46:24 +0200
From: Harald Tveit Alvestrand <[EMAIL PROTECTED]>
Subject: Re: Mersenne: Re: p-1
(about the chances of finding stuff at stage 2 of P-1)
At 16:37 24.04.2000 -0400, [EMAIL PROTECTED] wrote:
>We do things this way
>because a high percentage of general composites are
>of this form, i.e. have only one large prime factor.
curiosity (which killed the cat):
by now we should have some statistics - is the distribution
of factors ("one large" versus "all small" or "several large")
the same for Mersenne candidates as for "general
composites", or are Mersennes different?
This may influence the optimal setting of B1 and B2, as well
as being an interesting result.
Harald
- --
Harald Tveit Alvestrand, EDB Maxware, Norway
[EMAIL PROTECTED]
_________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
------------------------------
Date: Thu, 4 May 2000 09:16:51 -0700
From: "Richard J. Otter" <[EMAIL PROTECTED]>
Subject: Mersenne: Round off errors
I am running Mlucas_2.7z.ev4 on a Compaq Alpha machine.
My results file contains-
M 9392629 is not prime. Res64: 376484177C22AB08. Program: E2.7z
M 5028911 is not prime. Res64: E1C586E5AB9F9CB6. Program: E2.7z
M 9965533 is not prime. Res64: 6CDEFF74DD4859B2. Program: E2.7z
M10068757 Roundoff warning on iteration 126683 maxerr = 0.406250000000
M10068757 Roundoff warning on iteration 1992762 maxerr = 0.437500000000
M10068757 Roundoff warning on iteration 2747426 maxerr = 0.437500000000
M10068757 Roundoff warning on iteration 3383066 maxerr = 0.437500000000
M10068757 Roundoff warning on iteration 3941973 maxerr = 0.437500000000
M10068757 Roundoff warning on iteration 6161725 maxerr = 0.406250000000
M10068757 Roundoff warning on iteration 7988178 maxerr = 0.437500000000
M10068757 Roundoff warning on iteration 8877411 maxerr = 0.437500000000
M10068757 Roundoff warning on iteration 9634654 maxerr = 0.437500000000
M10068757 Roundoff warning on iteration 9803267 maxerr = 0.437500000000
M10068757 is not prime. Res64: AEED24F91193EE6F. Program: E2.7z
Is it safe to check in the last result?
Can I expect more of these errors in the future?
Thanks,
Richard Otter
_________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
------------------------------
Date: Thu, 4 May 2000 15:56:56 EDT
From: [EMAIL PROTECTED]
Subject: Mersenne: Re: alms for an ex-leap-year
(That's a Monty Python reference, for those who are puzzled by the the subject line.)
Harald Alvestrand wrote:
> one of the amazing things I discovered some years ago when browsing the
> website of the Institute for Earth Rotation (!) is that leap seconds can't
> be predicted more than approximately 5 years in advance.
>
> it's a strange world.
Spike Jones (live long and prosper, Spike :) wrote:
> Not so strange. The rule that always holds is the conservation of
> angular momentum. The uncertainty is in the moment of inertia of
> the earth. Movements in the tectonic plates cause slight variations,
> enough to throw off predictions of leap seconds. spike
I read an article a couple years ago in Science that showed how
even the daily cycle (used by many electric utilities around the
world) of
i) during high-demand (daylight) hours, supplement the 24-hour
power sources (e.g. fossil-fuel-burning or nuclear power plants)
by discharging water from a high-level to a lower-level reservoir;
ii) at night, use some of the now-regained excess capacity on the
electric grid to pump the water back up into the high reservoir
causes (like the proverbial skater pulling her arms in and back
out) a discernible variation in the Earth's rotation rate. I suppose
excavating a large open-pit mine and piling the tailings up on higher
ground would similarly cause a noticeable change. Sea levels rising
due to global warming should cause a very noticeable change in the
faster-rotation direction, if the ice that melted was originally
at a significantly higher elevation than the resulting sea level.
In fact, rotation-rate changes due to sea level change should be of
a similar order of magnitude as those due to tectonics, but would
occur on much shorter time scales. 'Tis fascinating stuff, albeit
wildly off-topic...
Cheers,
- -Ernst
_________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
------------------------------
Date: Thu, 04 May 2000 22:57:33 +0200
From: Martijn <[EMAIL PROTECTED]>
Subject: Re: Mersenne: Re: alms for an ex-leap-year
[EMAIL PROTECTED] wrote:
> ii) at night, use some of the now-regained excess capacity on the
> electric grid to pump the water back up into the high reservoir
>
> causes (like the proverbial skater pulling her arms in and back
> out) a discernible variation in the Earth's rotation rate. I suppose
> excavating a large open-pit mine and piling the tailings up on higher
> ground would similarly cause a noticeable change. Sea levels rising
> due to global warming should cause a very noticeable change in the
> faster-rotation direction, if the ice that melted was originally
> at a significantly higher elevation than the resulting sea level.
> In fact, rotation-rate changes due to sea level change should be of
> a similar order of magnitude as those due to tectonics, but would
> occur on much shorter time scales. 'Tis fascinating stuff, albeit
> wildly off-topic...
>
> Cheers,
> -Ernst
>
Regarding the sea level warming:
You forget that most of the ice is on the poles, while the
water is so to say all around. The latitude plays also an important
role. So the earth will slow down, much like the proverbial skater
pulling her arms from above her head and stretch them out to the sides.
Kind Regards, Martijn
- --
http://jkf.penguinpowered.com
Linux distributies voor maar
Fl 10 per CD, inclusief verzendkosten!
_________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
------------------------------
Date: Thu, 4 May 2000 17:46:46 EDT
From: [EMAIL PROTECTED]
Subject: Mersenne: Re: Mersenne Digest V1 #727
<< Movements in the tectonic plates cause slight variations, >>
Did you know that because we have a tendency to dam up rivers, there has been
a net movement of water away from the equator and toward the poles
(specifically, mostly this happens in the northern hemisphere), so human
activity is speeding up the rotation of the Earth. (Technically, the moon's
tidal drag is slowing it down even more, but we're reducing the moon's
slowing-down effect. :-P ).
Stephan "Ain't it cool?" Lavavej
_________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
------------------------------
Date: Thu, 4 May 2000 22:08:10 -0000
From: "Brian J. Beesley" <[EMAIL PROTECTED]>
Subject: Re: Mersenne: Re: p-1
On 3 May 00, at 14:46, Harald Tveit Alvestrand wrote:
> by now we should have some statistics - is the distribution
> of factors ("one large" versus "all small" or "several large")
> the same for Mersenne candidates as for "general
> composites", or are Mersennes different?
> This may influence the optimal setting of B1 and B2, as well
> as being an interesting result.
This _is_ an interesting question. However since we are dealing with
numbers (k in 2kp+1) which are "general" rather than "special" my
intuition (always dangerous!) would be that the "general" statistical
theory should be well obeyed.
The tested statistical theories relating to prime numbers seem to be
remarkably accurate e.g. one can predict the approximate number of
prime numbers in an arbitray interval which is fairly small in
comparison with the magnitude of the numbers themselves with very
good results with an absolutely minimal computing effort compared to
that needed to actually identify the primes in the interval.
Regards
Brian Beesley
_________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
------------------------------
Date: Thu, 4 May 2000 18:23:27 EDT
From: [EMAIL PROTECTED]
Subject: Mersenne: (no subject)
Martijn Kruithof <[EMAIL PROTECTED]> wrote:
> You forget that most of the ice is on the poles, while the
> water is so to say all around.
An excellent point. I was still thinking of hydropower reservoirs
while writing about the ice melting, and forgetting the implications
of the water getting redistributed globally in the latter case.
Thus, like the proverbial skater taking his foot out of his mouth...
Cheers,
- -Ernst
_________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
------------------------------
Date: Thu, 04 May 2000 19:58:54 EDT
From: "Nathan Russell" <[EMAIL PROTECTED]>
Subject: Re: Mersenne: Round off errors
>From: "Richard J. Otter" <[EMAIL PROTECTED]>
>To: <[EMAIL PROTECTED]>
>Subject: Mersenne: Round off errors
>Date: Thu, 4 May 2000 09:16:51 -0700
>
>I am running Mlucas_2.7z.ev4 on a Compaq Alpha machine.
>My results file contains-
>
>M 9392629 is not prime. Res64: 376484177C22AB08. Program: E2.7z
>M 5028911 is not prime. Res64: E1C586E5AB9F9CB6. Program: E2.7z
>M 9965533 is not prime. Res64: 6CDEFF74DD4859B2. Program: E2.7z
>M10068757 Roundoff warning on iteration 126683 maxerr = 0.406250000000
>M10068757 Roundoff warning on iteration 1992762 maxerr = 0.437500000000
>M10068757 Roundoff warning on iteration 2747426 maxerr = 0.437500000000
>M10068757 Roundoff warning on iteration 3383066 maxerr = 0.437500000000
>M10068757 Roundoff warning on iteration 3941973 maxerr = 0.437500000000
>M10068757 Roundoff warning on iteration 6161725 maxerr = 0.406250000000
>M10068757 Roundoff warning on iteration 7988178 maxerr = 0.437500000000
>M10068757 Roundoff warning on iteration 8877411 maxerr = 0.437500000000
>M10068757 Roundoff warning on iteration 9634654 maxerr = 0.437500000000
>M10068757 Roundoff warning on iteration 9803267 maxerr = 0.437500000000
>M10068757 is not prime. Res64: AEED24F91193EE6F. Program: E2.7z
>
>Is it safe to check in the last result?
>Can I expect more of these errors in the future?
>
>Thanks,
>Richard Otter
Well, I'm fairly new here so take everything I have to say with a grain of
salt.
I am going to somewhat 'water down' the language I use in this explanation
for two reasons: I do not fully myself understand such concepts as FFT
runlength, and I do not know how thoroughly you understand them.
The roundoff warnings essentially mean that the multiplication your machine
is less accurate than the developers thought it ought to be. It so happens
that the last number you tested has an exponent that is only a few hundred
thousand below the point at which it would choose to do a more accurate
multiplication.
The roundoff error is simply the distance that the result of the iteration
was from the nearest integer. As long as the nearest integer was the right
one, this is not a problem. However, if it was wrong, your whole result in
faulty. The Lucas-Lehmer test is completely intolerant of error and, in
fact, acts in such a way that the very next iteration after an error will
scramble the next term in the test sequence beyond recognition.
In order to ruin your work, the roundoff error would have to be greater than
.5; however, it will always appear as a value less than .5. Since none of
your roundoff errors are even near .5, it is reasonable to suppose that none
are over this value.
In any event, IMHO you should send the result. The worst thing that will
happen is that you will lose credit for it in a year or two, when someone
running double-checking finds a mismatch and someone else confirms the
problem. In this case, GIMPS will have expended no more effort than if you
did not turn in the result at all.
In case I have been unclear, these errors are in no way due to a hardware
problem with your machine, so there is no need to worry about that.
Best regards,
Nathan Russell
________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
_________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
------------------------------
Date: Fri, 5 May 2000 08:05:06 -0000
From: "Brian J. Beesley" <[EMAIL PROTECTED]>
Subject: Re: Mersenne: Round off errors
On 4 May 00, at 19:58, Nathan Russell wrote:
> The roundoff warnings essentially mean that the multiplication your
> machine is less accurate than the developers thought it ought to be.
Yes, those of us running Mlucas _know_ that there is a problem in
this area, with at least some architectures.
> It so
> happens that the last number you tested has an exponent that is only a
> few hundred thousand below the point at which it would choose to do a more
> accurate multiplication.
Less than that - the critical point in Mlucas 2.7z is 10110000 (cf
10320000 for Prime95). Obviously even this is a bit high for safety.
For the critical points for other FFT run lengths, refer to
ftp://209.133.33.182/pub/mayer/gimps_timings2.html
The reason why Mlucas should be "less accurate" is that the floating-
point hardware is pure IEEE G-float (53-bit mantissa) whereas, whilst
Prime95 stores FP values in memory in the same format, internal
calculations in the FP registers use a proprietary Intel format with
a 64-bit mantissa (plus sign, plus 15-bit exponent, making a length
of 80 bits in total - awkward on modern systems with native 32-bit,
or longer, data bus architecture!)
> The roundoff error is simply the distance that the result of the iteration
> was from the nearest integer. As long as the nearest integer was the
> right one, this is not a problem. However, if it was wrong, your whole
> result in faulty. The Lucas-Lehmer test is completely intolerant of error
Explanation perfect so far ...
> and, in fact, acts in such a way that the very next iteration after an
> error will scramble the next term in the test sequence beyond recognition.
Hmm. If you get just one bit wrong, in general terms the number of
suspect bits will double with each iteration.
> In order to ruin your work, the roundoff error would have to be greater
> than .5; however, it will always appear as a value less than .5.
If you report a rounding error of x then it means that the absolute
value of the difference between the computed value and the nearest
integer was x. Of course you could be measuring to the wrong integer,
e.g. if you went wrong by 0.7 you would pick the wrong integer &
return the roundoff error as 0.3.
For fairly obvious reasons you _can_ get a roundoff error of exactly
0.5 - but no bigger than that.
Depending on the FFT method used, there may actually be a strong
tendency for computed values of roundoff error to be of the form
k/2^n, where k is a fairly small integer. Now the following
information from Richard Otter's original message is interesting:
>M10068757 Roundoff warning on iteration 126683 maxerr =
0.406250000000
>M10068757 Roundoff warning on iteration 1992762 maxerr =
0.437500000000
>M10068757 Roundoff warning on iteration 2747426 maxerr =
0.437500000000
>M10068757 Roundoff warning on iteration 3383066 maxerr =
0.437500000000
>M10068757 Roundoff warning on iteration 3941973 maxerr =
0.437500000000
>M10068757 Roundoff warning on iteration 6161725 maxerr =
0.406250000000
>M10068757 Roundoff warning on iteration 7988178 maxerr =
0.437500000000
>M10068757 Roundoff warning on iteration 8877411 maxerr =
0.437500000000
>M10068757 Roundoff warning on iteration 9634654 maxerr =
0.437500000000
>M10068757 Roundoff warning on iteration 9803267 maxerr =
0.437500000000
>M10068757 is not prime. Res64: AEED24F91193EE6F. Program: E2.7z
There are only two values of roundoff error reported - 0.40625 =
13/2^5 and 0.4375 = 7/2^4. So it looks as though Mlucas has an
algorithm which generates k/2^n roundoff errors. Note that, if there
was a hardware problem, we'd expect to get at least some results not
following the k/2^n pattern.
> Since
> none of your roundoff errors are even near .5, it is reasonable to suppose
> that none are over this value.
I'd prefer to say that _none_ of the "preferred" values 29/2^6, 15/2^5, 31/2^6
are observed. It's unlikely (but not impossible) that we'd get an actual
roundoff >= 0.5 without hitting a value in (0.4375,0.5] at least occasionally.
> In any event, IMHO you should send the result. The worst thing that will
> happen is that you will lose credit for it in a year or two, when someone
> running double-checking finds a mismatch and someone else confirms the
> problem. In this case, GIMPS will have expended no more effort than if
> you did not turn in the result at all.
Absolutely.
Regards
Brian Beesley
_________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
------------------------------
Date: Fri, 5 May 2000 13:20:38 EDT
From: [EMAIL PROTECTED]
Subject: Mersenne: Re: Gregorian calendar
I'm no authority, but I swear my college astronomy book says:
Gregorian calendar established
%4 = leap
%100 = not
%400 = leap
and it also says the Russians added:
%4000 = not
but this is not part of the standard Gregorian definition.
There's some more calendar info at:
http://astro.nmsu.edu/~lhuber/leaphist.html and
http://www.calendarzone.com
Phil Brady
_________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
------------------------------
Date: Sat, 06 May 2000 22:45:20 EDT
From: "Nathan Russell" <[EMAIL PROTECTED]>
Subject: Mersenne: The sound of M(M(19))
Hi all,
While running ECM on this exponent I have noticed a throbbing sound,
somewhat similiar to a ceramic plate being spun on a hard surface; this
differs from the usual continuous hum of running an LL test. I have read
the FAQ entries relating to noise, but none of them mention a noise related
to ECM.
While I am satisfied that it is safe for the machine, I have, after
estimating that I can expect a long runtime, moved the assignment down my
worktodo file; some of the doublechecks I have saved up to run are nearly a
full million behind the current 'cutting edge', and I don't feel comfortable
slowing everything down by over a week.
In any event, though, I cannot help being somewhat curious about the source
of the sound. Does it relate to the writing to and from memory?
Nathan
________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
_________________________________________________________________
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 #728
******************************
