Mersenne Digest Saturday, May 19 2001 Volume 01 : Number 854
----------------------------------------------------------------------
Date: Wed, 16 May 2001 19:52:48 -0500
From: Ken Kriesel <[EMAIL PROTECTED]>
Subject: Mersenne: Spacing between mersenne primes
At 10:56 AM 5/16/2001 -0000, "Brian J. Beesley" <[EMAIL PROTECTED]> wrote:
>Another point - we're coming up to the second anniversary of the
>discovery of M38(?) - I think we're overdue to find another one!
It would be nice to find another soon. But I don't think we're overdue.
Long ago in Internet time I wrote:
Date: Thu, 29 Jan 1998 22:57:31 -0600
"In mersenne primality testing, exponents double in magnitude are much
more than double the work. For prime95 or the related versions,
each iteration takes about 2.1 times as long as an iteration for
half the FFT length, and there are twice as many iterations to perform,
per exponent. The odds of a number being prime diminishes as the
magnitude increases. Twice the FFT length is usable up to not quite twice
the exponent.
An interval of n to 2n contains nearly twice as many exponents as
the interval 1/2 n to n. In either of these intervals we expect
based on experience, to find about the same number of mersenne primes
on the average. (The actual rate of occurrence seems to be a little
bit in our favor for finding more primes in higher intervals, but it's
slight.) That makes about 3 factors of 2.
I think to maintain a constant rate of discovery of new primes, we would
need to maintain about an 8 or 9-fold increase of computing resources per
period of exponent doubling. Since exponent doubling has occurred in
about the past year, most of this must come in rapid growth in the cpu
pool, both by upgrades and by new membership. Otherwise we can expect
to droop back to a lower discovery rate. On average there are less than
2 mersenne primes per exponent doubling:
36 / [ln(2976221)/ln(2)] = 1.67 mersenne primes per doubling of exponent,
or about 37 / [ln(~3000000)/ln(2)] = 1.72 Mp's per doubling of p
(though we may have yet to find one in p < 2976221, or slightly above!)
In the long run the present discovery rate is unsustainable.
Even if we do drop back to a discovery rate of one per two years,
from the recent ~2 per year, we will have moved this area ahead by
years from its old curve. (The discovery rate was about 1 per 2 years
over the past 20 year interval and for the past 40 year interval.)"
Our experience described on http://www.mersenne.org/history.htm
bears this out. And there is no particular reason to expect the time
interval,
or the spacing between mersenne primes on a log or linear scale to be uniform.
It should vary about the expected curve.
Ken Kriesel
_________________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
------------------------------
Date: Thu, 17 May 2001 00:39:11 -0500
From: "Jeramy Ross" <[EMAIL PROTECTED]>
Subject: Re: Mersenne: SUMOUT errors
A interesting note, and I forgot to include this in my original post, but
the computer that I encountered the illegal sumouts on was a 500MHz K6 PC.
Perhaps this is a problem when running those software modems on a K6 based
machine??
- - Jeramy
Original Message ----- From: "Steve" <[EMAIL PROTECTED]>
For what it's worth, I have had the exact same problem getting illegal
sumouts when using the modem on this 475Mhz K6 PC.
_________________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
------------------------------
Date: Fri, 18 May 2001 01:17:45 +1000
From: Steve Phipps <[EMAIL PROTECTED]>
Subject: Re: Mersenne: ECM Question...
While we're on the subject, can someone explain how to derive the group
order for factors found using ECM? I've been carrying out ECM on an old PC
for almost a year now, and I'd like to be able to derive, and factorise,
the group orders for the factors that I've found.
I've been making an effort to understand the maths, and I'm getting there
slowly, but I've found nothing yet that explains how to derive the group
orders. If my understanding is correct, you would need to know the
equations used by mprime to derive the co-ordinates of the starting point
for each curve.
Anyway, if someone could explain how to derive the group order, or point
me in the right direction, I'd be very grateful.
Regards,
Steve
> If the sigma is the same, then a curve with B1=250000 will find any
> factor that a curve with B1=50000 finds.
> When you run 700 random curves at B1=250000, you might theoretically
> miss a factor that someone else finds with B1=50000, if he gets a lucky
> sigma so that the group order is very smooth. But in general, using the
> same number of curves, the higher bound should find all the factors that
> the lower bound can find.
> But dont be tempted into running only a few curves at very high bounds.
> The strength of ECM is that you can try curves with different group
> orders until a sufficiently smooth one comes along. So "skipping" bound
> levels is usually not a good idea unless you have reason to believe the
> the number unter attack has only large factors which call for a higher
> bound.
_________________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
------------------------------
Date: Thu, 17 May 2001 12:34:14 -0400
From: Nathan Russell <[EMAIL PROTECTED]>
Subject: Mersenne: Another ECM question
Is it (at least) theoretically possible that some larger factors are
unfindable with ECM due to the limited number of sigma producable by
George's random number generator?
Nathan
_________________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
------------------------------
Date: Thu, 17 May 2001 20:41:49 -0000
From: "Brian J. Beesley" <[EMAIL PROTECTED]>
Subject: Re: Mersenne: Spacing between mersenne primes
On 16 May 2001, at 19:52, Ken Kriesel wrote:
> At 10:56 AM 5/16/2001 -0000, "Brian J. Beesley" <[EMAIL PROTECTED]> wrote:
> >Another point - we're coming up to the second anniversary of the
> >discovery of M38(?) - I think we're overdue to find another one!
>
> It would be nice to find another soon. But I don't think we're overdue.
I have an old print of the Mersenne Search Status Page - it's dated
11/11/99. The point at which the "one LL" and "status unknown"
columns are equal is at about 7.75 million. On today's copy of the
same page, the crossover is about 11.5 million. So the ratio is about
1.5.
>
> Long ago in Internet time I wrote:
>
[... big snip ...]
> to droop back to a lower discovery rate. On average there are less than
> 2 mersenne primes per exponent doubling:
> 36 / [ln(2976221)/ln(2)] = 1.67 mersenne primes per doubling of exponent,
> or about 37 / [ln(~3000000)/ln(2)] = 1.72 Mp's per doubling of p
giving a ratio of ~2^(1/1.7) = 1.5.
BTW I agree absolutely with the analysis in your message. The
interval between the discovery of M37 and M38(?) was shorter than the
interval which has elapsed since the discovery of M38(?), despite the
unusual (and in the long term unsustainable) increase in power in the
CPUs installed in new PC systems during this time.
Maybe M39(?) is not massively overdue, but I think it is at least
about due now. However, random distribution means we could be unlucky
& not find another prime for two more years, or possibly even
longer... A new discovery would give the project a shot in the arm,
though!
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, 17 May 2001 23:01:12 +0100
From: "Peter Owen" <[EMAIL PROTECTED]>
Subject: Re: Mersenne: Re: 26 exponents
On 16 May 2001, at 10:56, Brian J. Beesley wrote:
[snip]
>
> Another point - we're coming up to the second anniversary of the
> discovery of M38(?) - I think we're overdue to find another one!
Has the discovery of M38(?) been published in a mathematics journal
yet, and if so, where?
Peter
_____________________________________
Peter Owen
11 The Downs
Blundellsands Road West
Liverpool L23 6XS
UK
mailto:[EMAIL PROTECTED]
_________________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
------------------------------
Date: Thu, 17 May 2001 18:47:21 -0400
From: Nathan Russell <[EMAIL PROTECTED]>
Subject: Mersenne: [OT] (fwd) [PrimeNumbers] Proth 6.6
- ----=_p7l8gtsvti9f3r08bso89ekcoa7qd3qq5i.MFSBCHJLHS
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
=46or those who are interested, Yves Gallot has released Proth 6.6,
which has great speed-ups for some architectures. =20
His post to the PrimeNumbers list follows.
Regards,
Nathan
- ----=_p7l8gtsvti9f3r08bso89ekcoa7qd3qq5i.MFSBCHJLHS
Content-Type: message/rfc822
Content-Disposition: inline
Return-Path:
<[EMAIL PROTECTED]>
Delivered-To: [EMAIL PROTECTED]
Received: (qmail 348 invoked from network); 17 May 2001 22:24:09 -0000
Received: from warmfront.acsu.buffalo.edu (HELO front.acsu.buffalo.edu) (128.205.6.88)
by mail4 with SMTP; 17 May 2001 22:24:09 -0000
Received: (qmail 17778 invoked by uid 83313); 17 May 2001 22:24:09 -0000
Received: (qmail 17732 invoked from network); 17 May 2001 22:24:08 -0000
Received: from ci.egroups.com (64.211.240.235)
by front with SMTP; 17 May 2001 22:24:08 -0000
X-eGroups-Return:
[EMAIL PROTECTED]
Received: from [10.1.4.56] by ci.egroups.com with NNFMP; 17 May 2001 22:24:05 -0000
X-Sender: [EMAIL PROTECTED]
X-Apparently-To: [EMAIL PROTECTED]
Received: (EGP: mail-7_1_3); 17 May 2001 22:24:05 -0000
Received: (qmail 12513 invoked from network); 17 May 2001 22:24:04 -0000
Received: from unknown (10.1.10.27) by l10.egroups.com with QMQP; 17 May 2001 22:24:04
-0000
Received: from unknown (HELO embelia.wanadoo.fr) (193.252.19.161) by mta2 with SMTP;
17 May 2001 22:24:04 -0000
Received: from villosa.wanadoo.fr (193.252.19.122) by embelia.wanadoo.fr; 18 May 2001
00:24:02 +0200
Received: from hal (193.248.213.226) by villosa.wanadoo.fr; 17 May 2001 23:51:50 +0200
Message-ID: <008301c0df1b$bdef46e0$0100a8c0@hal>
To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
From: "Yves Gallot" <[EMAIL PROTECTED]>
MIME-Version: 1.0
Mailing-List: list [EMAIL PROTECTED]; contact
[EMAIL PROTECTED]
Delivered-To: mailing list [EMAIL PROTECTED]
Precedence: bulk
List-Unsubscribe: <mailto:[EMAIL PROTECTED]>
Date: Thu, 17 May 2001 23:52:02 +0200
Subject: [PrimeNumbers] Proth 6.6
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Proth 6.6 is on the Web. This new release detects CPU with L2 cache on die
(new PIII and Celeron, P4) and with large L1 cache (Athlon and Duron). On
these processors, a different size is used for internal blocks. On a Celeron
800 for the GFN of the form b^65536+1, the version 6.6 is 10% faster than
the 6.5 and 20% faster than the 6.4. Now, on this computer the test of a GFN
having less than 3,000,000 digits is as fast as the test of a Mersenne
number with Prime95... and there are more GF primes not yet discovered in
this range than Mersenne primes!
Yves
Unsubscribe by an email to: [EMAIL PROTECTED]
The Prime Pages : http://www.primepages.org
Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
- ----=_p7l8gtsvti9f3r08bso89ekcoa7qd3qq5i.MFSBCHJLHS--
_________________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
------------------------------
Date: Fri, 18 May 2001 05:30:33 -0500
From: "Steve Harris" <[EMAIL PROTECTED]>
Subject: Re: Mersenne: Spacing between mersenne primes
Random distribution of Mersenne primes does indeed mean we may not find
another one for years, but it also means we may find the next two just a few
weeks apart.
There is also a nearly random order in which the first-time LL tests are
_completed_. Assignments are being given out around exponent 12.8 million,
but there are 9737 uncompleted in the 11-12 million range and 3496 in the
10-11 million range, as well as over a thousand below that... not to mention
the handful below M(39?). We could easily be unlucky enough to have 'skipped
over' one already, in which case it could be reported in any day now.
(And don't forget... one could have been found recently that hasn't been
published yet!)
Steve Harris
- -----Original Message-----
From: Brian J. Beesley <[EMAIL PROTECTED]>
Date: Thursday, May 17, 2001 4:35 PM
<snip>
Maybe M39(?) is not massively overdue, but I think it is at least
about due now. However, random distribution means we could be unlucky
& not find another prime for two more years, or possibly even
longer... A new discovery would give the project a shot in the arm,
though!
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, 18 May 2001 12:34:11 +0200
From: "tom ehlert" <[EMAIL PROTECTED]>
Subject: Overriding assigned exponent type (was Re: Mersenne: Re: 26 exponents)
Hi all,
some thoughts on reaching milestones earlier:
Assigned Exponents Report 18 May 2001 10:00
total
52819
to automatically generated "User ID" like S012345 [1]
10621 = 20%
to automatically generated "Computer ID" like C01234ABCD [2]
17870 = 33%
both User ID and Computer ID like S012345 C01234ABCD [3]
8040 = 15%
Cleared Exponents Report 18 May 2001 10:00
total
51788
by automatically generated "User ID" like S012345 [1]
6007 = 11%
by automatically generated "Computer ID" like C01234ABCD [2]
7034 = 13%
by User ID and Computer ID like S012345 C01234ABCD [3]
2746 = 5%
conclusion and proposal:
if the user didn't take the time to fill in his userID/
maschine ID, the chance, that he/she will not finish that
assignement is about 2-3 times higher then for other users,
as its reasonable to assume, that the
_average_ "S012345 C01234ABCD" user has roughly the same
hardware as the _average_ "jonmiller dads PIII" user.
and - probably all hardware geeks, that just want to have
a quick check of there maschine, will mostl likely be
"S012345 C01234ABCD" users, as they don't care about primenet.
proposal:
don't give out DC assignements below 5000000, if user/maschine
is Sddddd Chhhhhhhh.
don't give out LL assignements below 10000000, if user/maschine
is Sddddd Chhhhhhhh.
if the user wants lowest possible assigements, he must enter
at least one small 'x' in the ID.
that's not very elitarian and
very easy on the server side to implement
regards
tom ehlert
[1] C:>grep S[0-9][0-9][0-9][0-9][0-9]
results.txt >rsx.txt
[2] C:>grep :.*C[0-9A-F][0-9A-F][0-9A-F][0-9A-F][0-9A-F]
[0-9A-F][0-9A-F][0-9A-F] results.txt >rcx.txt
[3] C:>grep S[0-9][0-9][0-9][0-9][0-9].*C[0-9A-F][0-9A-F]
[0-9A-F][0-9A-F][0-9A-F][0-9A-F][0-9A-F]
[0-9A-F] results.txt >rsxcx.txt
_________________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
------------------------------
Date: Fri, 18 May 2001 13:16:09 +0200
From: "tom ehlert" <[EMAIL PROTECTED]>
Subject: Re: Overriding assigned exponent type (was Re: Mersenne: Re: 26 exponents)
I might have added:
assigned to User ID and Computer ID like ". C01234ABCD"
5322 = 10%
cleared by by User ID and Computer ID like ". C01234ABCD"
165 = 0.3%
assignments, that are next to be reassigned (timetogo < -50 days)
all 1549
S12345 471 = 30%
C1234ABCD 904 = 58%
Sxx Cxx 412 = 26%
. Cxx 368 = 23%
so, the ". Cxxxxxxxx" maschines are very uinproductive, too
tom
_________________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
------------------------------
Date: Fri, 18 May 2001 15:49:06 +-200
From: Denis Cazor <[EMAIL PROTECTED]>
Subject: Mersenne: Different results
Hello,
1) When testing a new Pc, I obtain two different results from the old and the new one
M9357637 is not prime. Res64: BCB1164E6826255E. WW1: C4F561C3,5448242,00000000
M9357637 is not prime. Res64: BCB1164E6826255E. WW1: C4F261C3,5448242,00030000
Are this results compatible ?
2) I often restart my new PC (for installation purpose of windows 98 se ...).
It seems Prime95 is beginning the calculus two early (?) and produce ILLEGAL SUMOUT
ERROR.
Instead of waiting five minutes, I can stop prime (test/stop menu) then continue
(test/ continue menu). Theire are no more errors after that.
Is there any way to delay prime95 starting calculus by one minute at boot time ?
Best regards,
Denis Cazor
_________________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
------------------------------
Date: Fri, 18 May 2001 10:38:49 -0400
From: Nathan Russell <[EMAIL PROTECTED]>
Subject: Re: Mersenne: Different results
On Fri, 18 May 2001 15:49:06 +-200, Denis Cazor
<[EMAIL PROTECTED]> wrote:
>
>Hello,
>
>1) When testing a new Pc, I obtain two different results from the old and the new one
>
>M9357637 is not prime. Res64: BCB1164E6826255E. WW1: C4F561C3,5448242,00000000
>M9357637 is not prime. Res64: BCB1164E6826255E. WW1: C4F261C3,5448242,00030000
>
>Are this results compatible ?
This issue, at least, I can deal with. The two results are the same,
but as it happens, in order to reduce the chance of a fatal code bug,
Prime95 'shifts' the initial inputs into its calculations by a certain
amount; that is why the last number in each result is different.
As another suggestion, you might want to use the Options -> Self-Test
option for testing new machines; this option uses pre-computed
results, and so you will not need to check the same number twice (a
rather time-consuming process); additionally, that option tests
Prime95's ability to test numbers of all sizes.
Regards,
Nathan Russell
_________________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
------------------------------
Date: Fri, 18 May 2001 07:47:10 -0700
From: "Aaron Blosser" <[EMAIL PROTECTED]>
Subject: Re: Mersenne: Different results
> 1) When testing a new Pc, I obtain two different results from the old and
the new one
>
> M9357637 is not prime. Res64: BCB1164E6826255E. WW1:
C4F561C3,5448242,00000000
> M9357637 is not prime. Res64: BCB1164E6826255E. WW1:
C4F261C3,5448242,00030000
>
> Are this results compatible ?
>
> 2) I often restart my new PC (for installation purpose of windows 98 se
...).
> It seems Prime95 is beginning the calculus two early (?) and produce
ILLEGAL SUMOUT ERROR.
> Instead of waiting five minutes, I can stop prime (test/stop menu) then
continue
> (test/ continue menu). Theire are no more errors after that.
>
> Is there any way to delay prime95 starting calculus by one minute at boot
time ?
Yup, it's the same. The Res64 is what's important there... it's the residue
left over after the final iteration (just the last 64 bits worth anyway...)
The WW1 is part of Scott's security check, just to make sure it's not been
falsely generated or some such. I assume part of it is related to the date,
time, or some other such thing which is why there's one part that's
different?
If you want to delay Prime95 starting up... hmm...not sure why you'd want to
do that, but...
Perhaps instead of having it run as a service, you could just put it in your
startup group so it doesn't run until you logon.
Or, make a batch file and use the SLEEP.EXE program (well, I know it comes
with the NT Resource Kit, and there's something similar for Win9x as well)
that'll wait for 60 seconds and then launch prime95. That can be setup in
the "runservices" key so it starts when the system boots.
Aaron
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
_________________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
------------------------------
Date: Fri, 18 May 2001 17:00:58 +0200
From: "Steinar H. Gunderson" <[EMAIL PROTECTED]>
Subject: Mersenne: Re: Different results
On Fri, May 18, 2001 at 07:47:10AM -0700, Aaron Blosser wrote:
>The WW1 is part of Scott's security check, just to make sure it's not been
>falsely generated or some such. I assume part of it is related to the date,
>time, or some other such thing which is why there's one part that's
>different?
Wouldn't the last part be the shift count?
/* 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: Fri, 18 May 2001 11:11:56 -0400
From: Jeff Woods <[EMAIL PROTECTED]>
Subject: Re: Mersenne: Different results
At 03:49 PM 5/18/01 +0000, you wrote:
>1) When testing a new Pc, I obtain two different results from the old and
>the new one
>
>M9357637 is not prime. Res64: BCB1164E6826255E. WW1: C4F561C3,5448242,00000000
>M9357637 is not prime. Res64: BCB1164E6826255E. WW1: C4F261C3,5448242,00030000
The RESIDUES matched above -- the result of the TEST is the same. The
last sections, 00000000 and 00030000, are not part of the result of the
test, but contains other information to help George and Scott know more
about the platform, equipment, and version of the software used to perform
the test.
_________________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
------------------------------
Date: Fri, 18 May 2001 08:18:34 -0700
From: "Aaron Blosser" <[EMAIL PROTECTED]>
Subject: Re: Mersenne: Re: Different results
> On Fri, May 18, 2001 at 07:47:10AM -0700, Aaron Blosser wrote:
> >The WW1 is part of Scott's security check, just to make sure it's not
been
> >falsely generated or some such. I assume part of it is related to the
date,
> >time, or some other such thing which is why there's one part that's
> >different?
>
> Wouldn't the last part be the shift count?
Um, could be. :) Let's face it, I'm not 100% sure what the last part is
there. I know there's the security check, but I dunno what the other stuff
is. You're probably right. :)
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
_________________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
------------------------------
Date: Fri, 18 May 2001 17:16:09 +0200
From: "Hoogendoorn, Sander" <[EMAIL PROTECTED]>
Subject: RE: Mersenne: Different results
>Hello,
>
>1) When testing a new Pc, I obtain two different results from the old and
the new one
>
>M9357637 is not prime. Res64: BCB1164E6826255E. WW1:
C4F561C3,5448242,00000000
>M9357637 is not prime. Res64: BCB1164E6826255E. WW1:
C4F261C3,5448242,00030000
>
>Are this results compatible ?
The 64 bits residue's are the same. The WW1 is the version number to see
which version of prime95 ran the test.
C4F261C3 is a checksum generated by the program to make sure the result is
really produced by the programm.
Don't know what 5448242 stands for, but the last part is an error counter so
the second one has had 3 errors.
Sander
_________________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
------------------------------
Date: Fri, 18 May 2001 12:13:33 -0400
From: Nathan Russell <[EMAIL PROTECTED]>
Subject: Re: Mersenne: Different results
On Fri, 18 May 2001 10:38:49 -0400, I wrote:
>This issue, at least, I can deal with. The two results are the same,
>but as it happens, in order to reduce the chance of a fatal code bug,
>Prime95 'shifts' the initial inputs into its calculations by a certain
>amount; that is why the last number in each result is different.
Several list members have pointed out that I was in error here; the
value that was different is either the error counter or contains
information about the platform being used. It looks to me like it
might be the error counter; in this case, three errors occured in one
run (I'm not sure which type of error). This might be reason to run a
fairly lengthy self-test on the machine.
Nathan
_________________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
------------------------------
Date: Fri, 18 May 2001 14:44:50 +0100
From: Steve <[EMAIL PROTECTED]>
Subject: Re: Mersenne: Spacing between mersenne primes
On Wed, May 16, 2001 at 07:52:48PM -0500, Ken Kriesel wrote:
> At 10:56 AM 5/16/2001 -0000, "Brian J. Beesley" <[EMAIL PROTECTED]> wrote:
> >Another point - we're coming up to the second anniversary of the
> >discovery of M38(?) - I think we're overdue to find another one!
>
> It would be nice to find another soon. But I don't think we're overdue.
>
> Long ago in Internet time I wrote:
Recently I've been thinking about this subject, and I've thought what if it
starts to work like a fractal, the more distance that you get between points
the greater chance there is of a point popping up right in the middle.
I'm not a mathamatician by any stretch of the imagination, but I think it's
an interesting theory.
- --
Cheers
Steve email mailto:[EMAIL PROTECTED]
%HAV-A-NICEDAY Error not enough coffee 0 pps.
web http://www.zeropps.uklinux.net/
or http://start.at/zero-pps
2:07pm up 105 days, 14:55, 2 users, load average: 1.14, 1.19, 1.13
_________________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
------------------------------
Date: Fri, 18 May 2001 14:15:48 -0400
From: George Woltman <[EMAIL PROTECTED]>
Subject: Re: Mersenne: Different results
Hi all,
At 03:49 PM 5/18/2001 +0000, Denis Cazor wrote:
>1) When testing a new Pc, I obtain two different results from the old and
>the new one
>
>M9357637 is not prime. Res64: BCB1164E6826255E. WW1: C4F561C3,5448242,00000000
>M9357637 is not prime. Res64: BCB1164E6826255E. WW1: C4F261C3,5448242,00030000
>
>Are this results compatible ?
Sigh, the rarely read readme.txt file says:
M1992031 is not prime. Res64: 6549369F4962ADE0. WV1: B253EF24,1414032,00000000
This means 2^1992031-1 is not prime - a Lucas-Lehmer test says so.
The last 64 bits of the last number in the Lucas-Lehmer sequence
is 6549369F4962ADE0. At some future date, another person will verify
this 64-bit result by rerunning the Lucas-Lehmer test. WV1 is the
program version number. B253EF24 is a checksum to guard against email
transmission errors. 1414032 can be ignored it is used as part
of the double-checking process. The final 00000000 value is a set
of 4 counters. These count the number of errors that occurred during
the Lucas-Lehmer test.
To elaborate, the 5448242 in your run is the shift count. Since your 2 runs
had an identical shift count, you undoubtedly started the second test using
a save file produced somewhere during the first test. An exponent will not
be considered double-checked unless the two runs have different shift counts.
The 00030000 shows that you had 3 ILLEGAL SUMOUT errors on one
machine and no errors on the other. The four counters - one byte each -
are: count of reproducible errors, count of illegal sumouts, count of
roundoff > 0.40, count of sum(inputs) != sum(outputs).
>2)
>It seems Prime95 is beginning the calculus two early (?) and produce
>ILLEGAL SUMOUT ERROR.
>Instead of waiting five minutes, I can stop prime (test/stop menu) then
>continue
>(test/ continue menu). Theire are no more errors after that.
This suggestion is actually a high priority for the next release. The
error is probably caused by some driver or program initialization that isn't
saving the FPU state properly. The error is benign as you found out.
I think the main advantage of this feature is it will lead to slightly faster
boot times and thereby improve prime95's reputation of not interfering with
your everyday work.
Regards,
George
_________________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
------------------------------
Date: Fri, 18 May 2001 14:47:49 -0400
From: George Woltman <[EMAIL PROTECTED]>
Subject: Re: Mersenne: Spacing between mersenne primes
Hi,
At 02:44 PM 5/18/2001 +0100, Steve wrote:
> > >Another point - we're coming up to the second anniversary of the
> > >discovery of M38(?) - I think we're overdue to find another one!
> >
> > It would be nice to find another soon. But I don't think we're overdue.
The Sept 30, 1999 status.htm page showed 3.12 expected new Mersenne primes
to be found below 20.4M. The latest status.htm page shows 1.49. So during
that time we found zero primes instead of the expected 1.63 primes. By no
means unusual, but it is unlucky.
Another way to look at it. Roughly speaking supercomputers owned the
region below 1.3M, GIMPS above that. We've roughly tested three "doublings"
1.3M to 2.6M, 2.6M to 5.2M, 5.2M to 10.4M. There are 1.78 an
expected Mersenne primes per doubling. GIMPS should have found 5.34 primes.
Oh well, maybe the 10.4M to 20.8M doubling will be especially rich in new
Mersenne primes :)
Regards,
George
_________________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
------------------------------
Date: Fri, 18 May 2001 15:32:02 -0400
From: Nathan Russell <[EMAIL PROTECTED]>
Subject: Re: Mersenne: Spacing between mersenne primes
On Fri, 18 May 2001 14:47:49 -0400, George Woltman wrote:
>Another way to look at it. Roughly speaking supercomputers owned the
>region below 1.3M, GIMPS above that. We've roughly tested three "doublings"
>1.3M to 2.6M, 2.6M to 5.2M, 5.2M to 10.4M. There are 1.78 an
>expected Mersenne primes per doubling. GIMPS should have found 5.34 primes.
Another way to look at it is that we were unlucky with two doublings,
and slightly lucky with one.
Note that the M#35/M#36 split is, while nowhere near the widest known,
unusually wide, so we were unlucky there too.
These things, of course, are totally unpredictable - there is one
precedent for adjacent exponents (M127 and M521) having a ratio of
4.102, which means it wouldn't be a record even if we found no new
primes through the ~25M range. Here's hoping that isn't the case!
Nathan
_________________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
------------------------------
Date: Fri, 18 May 2001 22:02:05 +0000 (GMT)
From: Russel Brooks <[EMAIL PROTECTED]>
Subject: Mersenne: Apple vs. GIMPS
I'm contemplating getting a Apple, probably an IMac. I think
I've seen Gimps for the Apple, am I right? How well does an
Apple running Gimps compare to a Pentium/Win* combination?
Of sourse Gimps wouldn't be the only thing I run but I would
like to run it on any pc I have access to.
Cheers... Russ
_________________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
------------------------------
Date: Sat, 19 May 2001 09:16:56 -0000
From: "Brian J. Beesley" <[EMAIL PROTECTED]>
Subject: Re: Mersenne: Different results
On 18 May 2001, at 14:15, George Woltman wrote:
> This suggestion is actually a high priority for the next release. The
> error is probably caused by some driver or program initialization that
> isn't saving the FPU state properly. The error is benign as you found
> out. I think the main advantage of this feature is it will lead to
> slightly faster boot times and thereby improve prime95's reputation of
> not interfering with your everyday work.
Could I respectfully suggest:
(a) the startup delay (in seconds) is included as a setting in
local.ini and would default to zero, except for NTPrime and Prime95
when "run as service" is set, when the default would be 60 seconds;
(b) a command-line switch is provided which would cause the startup
delay to be omitted, even if set in local.ini.
Regards
Brian Beesley
_________________________________________________________________________
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 #854
******************************
