Mersenne: Computing meltdown???

[Eric Hahn]

It appears that the message forwarding service is still down...
and that v22 seems to have a problem in dial-up connections...
attempting to force a dial-up and connnect to PrimeNet and
after a great deal of time... finally erroring out... instead
of checking to see if there is a connection present before
attempting to communicate... and if not...  waiting... and
checking back later... to communicate when there is...

Closely examining the Assignment Report... I've noticed
that... mostly due to the message forwarding service being
down... but also maybe a little from the v22 problem... only
approximately 37% of assignments have been updated within
the last **5** (FIVE) weeks...  This is in comparison to
the > 90% updates for the same period... over the last
year...

Are we going to have a major computing power meltdown???
Perhaps in the number of PCs using the client... or users
continuing to work on the project???  1/3 of the current
computing power is still a lot of computing power... but
a major... and significannt drop...

Eric


_
Unsubscribe & list info -- http://www.ndatech.com/mersenne/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Re: Mersenne: Re: Mersenne Digest V1 #1080

[Eric Hahn]

Robert Braunwart wrote:
>I'm having trouble with one of my computer contacting PrimeNet.
>It is supposed to connect every day, but hasn't connected for
>two weeks.  I get the Error 29 message.  I have looked at the
>explanation for Error 29 at PrimeNet, but none of the four
>possibilities apply to me.  I am running Prime95 v. 21.4 and
>have not upgraded in a long time.  Also, I have been running
>Prime95 on this computer for a long time.  Any suggestions?

Bob...

  The message forwarding service is still obviously down :-(
George was going to ask Scott if he could get Entropia to 
restart the service again... about a week ago...  It still
hasn't been apparently... since a number of clients I have,
haven't been able to contact the server since June 27th...

  Hopefully, the service can be restarted in the next two
weeks... or there could be a considerable amount of 
re-assignments of exponents by PrimeNet...

  The best solution might be upgrading to v22, but again,
unfortunately, that may not be possilbe for a number of users,
who don't have access to certain clients anymore...  In which
case, there COULD BE... a significant decrease in computing
power to the project :-(

Eric


_
Unsubscribe & list info -- http://www.ndatech.com/mersenne/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Re: Mersenne: Old files in my mprime dirs

[Eric Hahn]

Daran wrote:
>> Actually the .001 extension would be expected... especially
>> if running MPrime on a dual CPU box... with one instance using
>> the -A1 switch...  Using the -A switch will put an extension
>> with the instance after it... No -A switch... no extension...
>
>OK.  I've never used a Dual CPU Box.

Actually... it doesn't matter whether it's a dual CPU box or
not... it all depends on the -A switch... You could set up
two instances on a single CPU box... and put a Time= line in
the prime.ini file(s)... and have one without the -A switch
running L-L tests at night... and one with the -A switch
running factoring during the day... to reduce memory use...
Note: ECM and P-1 use the -A switch for extensions... but the
L-L tests and trial-factoring do not... L-L will only add an
extension equal to iteration / X  (where x is from
interimfiles=X in prime.ini)... if interimfiles= is present...

>> However... to complete the P-1s... assuming they were initiated
>> by a L-L test... adding Pfactor=exponent,66 lines to the
>> WORK0001.INI would do it... no ,1 is needed... since it would
>> indicate the P-1 is complete...
>
>Not for Pfactor assignments it doesn't.  Here's what undoc.txt
>says
>[...]
>I have verified that this is correct.  A '1' in the last place
>causes it to choose DC limits.

OK... but if the test were in progress... and not completed...
MPrime has already chosen the limits... Restarting it with the
DC limits... which might be different... would cause MPrime to
restart the P-1 tests from scratch...  A factor might be found...
but if Chris didn't want to go thru the trouble... he might as
well delete the files... since when double-checking gets there...
the P-1 will be done... since PrimeNet doesn't know it was even
started...

>One question:  If Chris is going to finish them on a different
> - single CPU machine, would he have to remove the extension?

Not if Chris used the -A1 switch to run the tests... but it
would be easier to just remove the extension... and not use
the -A switch entirely... if using a single CPU box... and
only one instance of MPrime...

Eric



_
Unsubscribe & list info -- http://www.ndatech.com/mersenne/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Re: Mersenne: Old files in my mprime dirs

[Eric Hahn]

Daran wrote:
>Chris Marble wrote:
>
>> What happened that these files were left around a year ago?
>
>They shouldn't have an extension, so I'm gessing.   Backup
>and restore?  Recovered from a damaged filesystem?
>
>My recommendation would be to complete the P-1 as though
>they were DCs.  Just remove the extensions and put
>Pfactor=exponent,66,1 into your P-1 factory's worktodo file.

Actually the .001 extension would be expected... especially
if running MPrime on a dual CPU box... with one instance using
the -A1 switch...  Using the -A switch will put an extension
with the instance after it... No -A switch... no extension...

However... to complete the P-1s... assuming they were initiated
by a L-L test... adding Pfactor=exponent,66 lines to the
WORK0001.INI would do it... no ,1 is needed... since it would
indicate the P-1 is complete...

Eric

_
Unsubscribe & list info -- http://www.ndatech.com/mersenne/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Re: Mersenne: Old files in my mprime dirs

[Eric Hahn]

Chris Marble wrote:
>I've been running mprime on Linux for a bit less than 2
>years now. I was looking at the directory on one box
>and found some ancient files:
>mE013037.001
>mF320219.001
>mF550789.001
>mF614243.001
>mF687599.001

>These are from a dual CPU box.  The leading m suggests
>they're from factoring but but file sizes are 3.5 to 3.9 MB.

These are from P-1 runs... not factoring...  The first letter
will determine the test... E = ECM... M = P-1...
P = Trial-Factoring OR L-L...  Trial-factoring files are
always 32 bytes...

The fact that they are 3.5 to 3.9 MB indicates... that they
all are P-1 tests in progress... and not completed...
Prime95 (and MPrime) will delete P-1 files automatically
if run as part of the L-L test...  If they were P-1 tests
run by themselves... and completed... they would be from
1.75 to 2 MB...

You are correct... however... in assuming that E=14 and
F=15... in this case...  To check what happened to these
exponents and the results... and whether they were reported
to PrimeNet... you will have to look at the RESU0001.TXT and
PRIM0001.LOG...  RESU0001.TXT will give whatever results
Prime95/Mprime came up with... and PRIM0001.LOG will tell
what results... in any... were reported to PrimeNet...

>What happened that these files were left around a year ago?

If the P-1 was part of an L-L test... there could've been
a crash or something... that prevented Prime95/Mprime from
completing the tests... and therefore not deleting the files...

Eric


_
Unsubscribe & list info -- http://www.ndatech.com/mersenne/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

P-1 (was Re: Mersenne: Why is trial factoring [....])

[Eric Hahn]

Brian Beesley wrote:
>If you have a reasonable amount of memory on your system I'd
>reccomend running P-1 on selected exponents just above 1
>million - use the pminus1 database file to direct your work.
>Otherwise ECM on small exponents, or trial factoring on those
>exponents which have not been done "deep enough" - there
>are a considerable number of these in the 6M - 8M exponent
>range.

  If anybody is interested in P-1'ing exponents just above 
1 Million...  I am just finishing the range 1,000,193 -
1,001,089 to the limits B1=10M, B2=1B... and can provide
the save files from the exponents in this range...
(for deeper testing)...

  I will note however... that even on a decent machine...
an Athlon 1.4GHz... it has taken approx. 5.4 days for each
exponent to get to these limits... and will only increase
as the limits do...

  Since... IMHO... the odds of finding a factor using P-1
on these exponents... even increasing to the limits of
Prime95... (4.29B)... is low... I am going to start
attempting to ECM these exponents to a depth of 30
digits... (B1=250K, B2=25M)...

  If unsuccessful on the ECM to 30 digits... than I
will just stick to the 3 main other tasks/ranges
I am already working on

Eric Hahn


_
Unsubscribe & list info -- http://www.ndatech.com/mersenne/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Re: Mersenne: Why is trial factoring of small exponents slower than large ones?

[Eric Hahn]

G W Reynolds wrote:
>I am using mprime 22.12 on a pentium 166 MMX to do trial
>factoring. For the exponents currently being assigned from
>primenet it takes this machine about 12 minutes to factor
>from 2^57 to 2^58.
>
>I thought I would try factoring some small exponents (under
>1,000,000) from the nofactors.zip file. I put
>FactorOverride=64 into prime.ini and started mprime as usual
>but progress is _much_ slower, it will take about 8 hours to
>factor from 2^57 to 2^58.
>
>Can someone tell me why the time difference is so great?

The number of potential factors and time required to attempt
to trial-factor exponents are inversely proportional to the
exponent... and proportional to the bit-depth...

All potential factors are in the form 2kp+1... The smaller
the p (the exponent)... the more potential factors in any
given bit-depth...

Basically... If you cut the exponent in 1/2... you will have
approximately TWICE as many potential factors to test... and
therefore it will also take approx. TWICE the time to trial-
factor that exponent... (assuming trial-factoring to the same
bit-depth for each exponent)...

But... If you increase the bit-depth... you will DOUBLE the
number of potential factors to test... for each bit-depth you
increase by... (ie: 2x for 2^57 to 2^58... 4x for 2^57 to
2^59... 8x for 2^57 to 2^60)...

To keep the approx. same number of potential factors to
test... for any given trial-factoring attempt... you could
DOUBLE the exponent AND increase the bit-depth by ONE...
(ie: go from p=20M to p=40M and factor from 2^57 to 2^58
instead of from 2^56 to 2^57...)

FYI... Trial-factoring the range 70M-75M... from 2^60 to
2^62... is taking approx. 1.25 hours/exponent on a P2-266...
which is approx. 2x as fast as a P166-MMX...  (Thankfully I
have more than one machine working on this range :-) )

Eric Hahn

P.S. By factoring exponents around 1M instead of 20M... and
factoring to 2^64... instead of from 2^57 to 2^58... you are
increasing the number of potential factors (and hence the
time required)... by an approx. 2048x...  That reduces down
to instead of 12 MINS from 2^57 to 2^58 at p=20M to 
17 DAYS for p=1M from 2^57 to 2^64... :-(


_
Unsubscribe & list info -- http://www.ndatech.com/mersenne/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Mersenne: ECM

[Eric Hahn]

Not knowing a whole lot about ECM... I thought I'd
ask this question... and maybe put out a new topic
to discuss... ;-)

Let's say you've done 700 curves with B1=25,000 to
find a factor up to 30-digits... and you've been
unsuccessful... :-(

Now you've decided to try 1800 curves with
B1=1,000,000 to try and find a factor up to
35-digits.

Do you have to start from scratch... or can you
somehow use the information from attempting to
find a factor up to 30-digits... to save some
time and energy... and speed up the search
process at the same time???

Eric... (finder of over 150,000 factors (and climbing))


_
Unsubscribe & list info -- http://www.ndatech.com/mersenne/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Re: Mersenne: Poaching and related issues...

[Eric Hahn]

At 09:50 AM 1/25/03 -0600, Shane Sanford wrote:
>> Increasing the difficulty for a poacher to _find_ a tempting
>> target would mean other participants could be less concerned
>> about making themselves into such a target, and just
>> concentrate on doing the work they considered most suitable
>> within the rules.
>
>If the rules you are referring to include the possible new
>guidelines George proposes  (which in a nut shell goes
>something like this -- snips taken from a couple of posts
>on the forum by George) 
>
>
>"Consensus seems to be building around a sliding scale. It's
>2 to 3 months for the smallest double-checks and first-time
>tests (to avoid holding up milestones), 6 months for recycled
>exponents, 12 months for an exponent at the leading edge. 2+
>years for a 33M exponent.
>
>Give or take."
>
>
>"A leading edge first time test today is unlikely to hold up a
>milestone for maybe 2 years. I'm not advocating yanking a
>reservation just because you've had it one year.
>
>I think we are proposing reassignment if you take more than
>a year and some other criteria is met such as:
>a) You aren't making significant progress.
>b) You are holding up a milestone.
>c) Require the user to fill out a web form saying "I'm still
>working on it"


  Even these guidelines though... are NOT going to stop any
poacher intent on doing such, to complete a small exponent
so a milestone can be reached... OR for any other reason...


>I whole heartily believe the best way to eliminate poaching is
>to  minimize the reasons there are poachers to begin with rather
>than trying to  make it more difficult to do.  Even masking the
>exponents has a big loop hole in that it would take years to
>become effective even if implemented today.  All that has to
>be done is to save a copy of status.txt today and you know a
>very very big chunk of the exponents that will fall in the
>trailing edge of the assignment list of many many years.
>After that it's a trivial matter of elimination to deduce
>which is which when masked.

  IMHO, NO system whatsoever, will be able to prevent a poacher
intent on doing such. ANY system that is used, is going to have
a flaw or loophole of some kind.  We could eliminate the status
reports completely, and only assign exponents blindly, but even
that won't work.  The only thing it would do is make a whole lot
more work for some individual, which would most likely be George.

  Even this possible new system for the server assignments is
flawed.  Let's say a maximum time limit is set and reached. The
exponent is expired and is re-assigned.  How do we know that
exponent won't be expired time and time again???  The answer
is, that we don't, and any poacher intent on doing such, knows
that too, and is going to poach the exponent... NO IFS, ANDS or
BUTS...

  ANY system... and I mean ANY system is not going to prevent
poaching from happening.  Did prohibition stop the sell and
consumption of alcohol???  It reminds me of the saying "When
guns are outlawed, only outlaws will have guns!"  Any person
determined to poach, is going to find a way to do such, no
matter what system is used to prevent it!

  The best solution is probably strong discouragement of the
practice of poaching. eminding EVERYBODY that not only is
poaching NOT sanctioned, but that the time spent poaching is
wasted, and could have been used to further the project
otherwise. Also note that the poacher themselves are risking
being poached themselves, and that even more time is wasted
as the exponent is tested for the 5th time, when just a 2nd test
would have been sufficient.

  Using the example from my previous post, 2 exponents taking
5 days to test, and being tested 5 times instead of 2, is
wasting 15 days worth of times that could have been used to
complete 6 additional trailing-edge tests, or maybe 2 additional
leading-edge tests.  

  Maybe not so significant is the grand scheme of the project
overall, but maybe as far as reaching certain milestones, it is.
Sort of makes you wonder, just what milestone the project would
be on, if NO POACHING was occurring.  Maybe all exponents under
8 million could have been tested by now, instead of just under
7 million.  

  OK... I'll shut up again... and go back to my own work...
(some of which I might add is FAR OUTSIDE of Primenet ranges,
but HAS STILL BEEN POACHED on occassion!)...

Eric


_
Unsubscribe & list info -- http://www.ndatech.com/mersenne/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Re: Mersenne: Poaching -- Discouragement thereof

[Eric Hahn]

>On Wednesday 22 January 2003 22:50, Richard Woods wrote:
>> Here's what I've just posted in the GIMPS Forum.
>>
>> - - -
>>
>> _IF_ PrimeNet has automatic time limits on assignments, ordinarily
>> requiring no manual intervention to expire assignments or re-assign
>> them, then why would any GIMPS participant, other than a system
>> administrator or a would-be poacher, need to know someone else's:
>>
>> (a) current iteration,
>>
>> (b) days-to-go,
>>
>> (c) days-to-expire, or
>>
>> (d) last date-updated?
>>
>> If there's no non-poaching non-administrating user's need-to-know for
>> those items, then just stop including them in public reports. Include
>> them only in administrative reports and private password-requiring
>> individual reports.
>>
>> That would deny target-selecting information to would-be poachers,
>> right?
>
>Sure. So would eliminating the report altogether. 

  I'll add my 2 cents worth to this by saying what difference
does it really make how detailed the reports are???  Any
report, no matter how detailed, can be used for both good AND
bad, just like anything else.  When they split the atom, did
anybody foresee it being used to drop the bomb???  When they
discovered they could transplant organs, did anybody foresee
people being murdered for black-market transplants???  

  My point is, if somebody is going to poach exponents, whether
it's sanctioned or not, how detailed the report is, doesn't make
a single bit of difference.

  Here is a very good example, having just looked at the 
Assigned Exponent Report.  There are two exponents below
7 million out being double-checked.  If somebody wants to
have everything under 7 million checked sooner than later,
and they know they can test both exponents in say 5 days,
they are going to do it, no matter what. It doesn't matter
whether the report looks like:

 6715589 D*  64   506675260.9  14.2  74.2  14-Jan-03 22:02  24-Nov-02
20:49  crown  bubak
 6977699 D*  64   6750207   233.7 -27.2  22.8  17-Dec-02 13:16  05-Jun-02
02:23  guizuzaguizuza

 OR looks like:

 6715589 D*   crown  bubak
 6977699 D*   guizuzaguizuza

  Why??  Because the poacher knows they can do both in 5 days!
It doesn't matter whether the current assignee is on iteration
1 or 6715580, or has been assigned the exponent 1 day or 350
days. The poacher is going to do the exponents anyways.  Besides
that, if there is more than one poacher, they're taking a chance
that somebody else hasn't already poached the exponent, and 
they are checking it for the 5th time.  Again, it doesn't matter
how detailed the report is.

  Personally, IMHO, I like to see all the details, just to get
a general idea of how things are progressing.  Maybe it's
because it's math, math is all about numbers, and I like numbers.
(you know, the more details, the more numbers there are!)

  If anything was changed in the reports, I would say I would
like to see the reports accurately report factoring depth, but
even George's files don't do that (because of the .5 adjustment
used for P-1). If a exponent says it's been tested to 2^68, how
do you know it's 2^68, or whether it's 2^67, with P-1 having
been done as well???  But that is so minor of a thing, it's 
only a glancing thought.

  OK... I'll shut up now... and get back to more mersenne
testing...

Eric Hahn






  

  


_
Unsubscribe & list info -- http://www.ndatech.com/mersenne/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Mersenne: Primenet Summary Report

[Eric Hahn]

Has anybody else had trouble with the PrimeNet Summary
Report (SUMMARY.TXT) at:
http://mersenne.org/primenet/summary.txt
(or even in the World Test Status)???

No matter when... every time I try to view it...
it is never complete... It usually is terminated
at approx. the 19M mark...

None of the other pages or reports have any 
problem... just that particular one...

Eric


_
Unsubscribe & list info -- http://www.ndatech.com/mersenne/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Mersenne: Range of 41,564,021 - 42,521,373

[Eric Hahn]

I am posting this message to both this list and the
LoneMersenneHunters group on Yahoo...

As of this date... I have told by 6 people... that they
would like to do work in this range... (that I had
previously stated I was testing)... and have started
doing work... some of which is being duplicated... :-(

If you would REALLY like to work in this range... if
only hoping to discover what MIGHT be a mersenne prime...
please contact me... and let me know what you are doing...
(and any results)... so that work is NOT being duplicated
unnecessarily... Even on a Athlon running at 1333MHz...
it takes a full week to trial-factor to 2^69... if no
factor is found... several days for P-1... and at least
8 mos. to LL-Test...

I DO NOT have any problems with people wanting to do
work in this range... but please note... there is NO
GUARANTEE that a mersenne prime exists in this range...
and I assume NO LIABILITY if there is NOT!!!  But
please... let's work together... and cooperate... and
NOT DUPLICATE WORK

THANK YOU SO MUCH!!!

Eric

_
Unsubscribe & list info -- http://www.ndatech.com/mersenne/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Mersenne: ECM

[Eric Hahn]

OK...

  I think I know the answer to this... but want to
double-check to be sure...

  While doing factoring... using ECM... factors up to:
 15 digits is the equivalent of ~2^50...
 20 digits is the equivalent of ~2^67...
 25 digits is the equivalent of ~2^83...
 30 digits is the equivalent of ~2^100...

  If trial-factoring has been done up to 2^68... is it
possible to skip testing ECM curves for factors up to 15
and/or 20 digits... and go straight to testing ECM curves
for digits up to 25 digits???

Eric


_
Unsubscribe & list info -- http://www.ndatech.com/mersenne/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Mersenne: Media Relations (WAS: Mersenne Digest V1 #950)

[Eric Hahn]

Bruce Leenstra wrote:
>Gareth Randall writes:
>> So do we need a overview of the GIMPS project on mersenne.org
>>(perhaps even linked to as "notes for journalists") which gives
>> the core facts so that people don't keep getting it wrong?
>
>A very good idea. Do we have any volunteers for "GIMPS Media Relations
Coordinator" in charge of the Media Relations Webpage?
>
>YotN,  Bruce Leenstra

I agree that it is a VERY GOOD IDEA!!!  It wouldn't take
much effort to do either...  I would be more than willing
to volunteer... if nobody else has any objections...

Eric


_
Unsubscribe & list info -- http://www.ndatech.com/mersenne/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Re: Mersenne: Fwd: Predicting Mersenne Primes

[Eric Hahn]

  H  I'm not going to say a SINGLE WORD!!!   Especially considering
it appeared NOBODY had ever noticed that post...  

  As Enron executives have been saying... "I would like to
reserve my right to remain silent under the 5th amendment..."

Eric

== ORIGINAL MESSSAGE ==
George Woltman wrote:
>I'll forward your attempted post.  I don't remember Eric's >prediction,
but if true it is quite insightful (or lucky).
>
>
>>From: "Dale Horn" <[EMAIL PROTECTED]>
>>Subject: Predicting Mersenne Primes
>>
>>I tried to post this on the Mersenne mailing list at >>[EMAIL PROTECTED],
but it never showed up.
>>I was wondering if is was possible to predict where a Mersenne
>>Prime will be?
>>I ask because I was looking at the mersenne.org website and
>>noticed that it states that on December 6, 2001, the 39th
>>known Mersenne Prime was found. It was listed as 2^13466917-1.
>>I was also looking through some of the past digests from the
>>list and noticed that an Eric Hahn posted a message on July 30,
>>2000, stating that one of the ranges a Mersenne Prime should be
>>found was between 2^13430227-1 and 2^13501387.


_
Unsubscribe & list info -- http://www.ndatech.com/mersenne/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Re: Mersenne: 39th Mersenne Prime

[Eric Hahn]

"danny fleming" <[EMAIL PROTECTED]> wrote:

>To Whom It May Concern:  
>
>I have devised a method of easily figuring out 
>
>approximately how many prime numbers are before
>
>a given prime.  Here it is:  since the natural
>
>logarithm of a number increases +2.3 for every
>
>power of 10, the 39th Mersenne Prime, since it 
>
>contains 4,053,946 digits, is the 4,053,945*2.3=
>
>9,324,074th prime number.  Even more sophisticated
>
>methods can come even closer, it might make it easier
>
>to find unknown primes.  
>
>Sincerely yours,
>Danny Karl Fleming  

  Hm interesting math!!  According to the info I have available...
the 9,324,074th prime number would be somewhere around 166,800,000... which
places it between 2^27 and 2^28...

  Last I heard the 39th Mersenne Prime was 2^13,466,917-1... a far cry from
2^28

Eric


_
Unsubscribe & list info -- http://www.ndatech.com/mersenne/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Mersenne: Hyper-threading

[Eric Hahn]

Found this article on News.com about the new Pentium 4's
coming out next year... code-named Prescott.  It mentions
a speed of 4GHz... and the use of hyper-threading...
Hyper-threading is supposed to allow two applications or
application threads to run on one processor at the same
time... by allowing one application (or thread) to use
parts of the processor it needs... and the second
application (or thread) to use others...

Esentially this could speed up testing even more... by 
having one thread of Prime95 use the FPU... while another
uses the IAU...

The article also mentions AMD's Clawhammer due out the 
end of this year... able to run 64-bit applications...
This could significantly reduce the number of 
adds/multiplies required for testing


_
Unsubscribe & list info -- http://www.ndatech.com/mersenne/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Mersenne: Re: MERSENNE: Factoring Failure?

[Eric Hahn]

Steve Harris wrote:
>-Original Message-
>From: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
>Date: Tuesday, October 02, 2001 3:44 PM
>Subject: Re: FW: Mersenne: Re: Factoring Failure?
>
>
>> > Either way, GIMPS
>> > has never considered missing a factor as a big deal.  It
>> > only means some wasted effort running a LL test that could
>> > have been avoided.
>
>>True enough - though I'm concerned that the "no factors below 2^N"
>>database may be seriously flawed, from the point of view of GIMPS
>>it would seem to be a waste of time to go round redoing trial
>>factoring just to fix this problem.
>
>Yes, from the point of view of GIMPS (that is, searching for
>Mersenne primes) it's not a huge deal... but there also exists
>an effort to fully factor the candidates that are not prime,
>and this throws a big problem into that project. Someone could
>be trial factoring an exponent from 2^59 to 2^65 and find a
>factor in that range after a smaller factor had been missed,
>and it will go into the database as the smallest factor when
>it actually is not. Might be decades before the smaller factor
>is discovered.

Actually... IIRC... George noted once that the database of
smallest KNOWN factors was just that... and did NOT
necessarily mean that it contained the smallest factors of
any given exponent...  

There was a bug in a previous version (v19??) which caused
Prime95 to not continue trial-factoring to find a smaller
factor after one had been found and it had been stopped
(or went to sleep)... There was also the advent of P-1
factoring which does not necessarily find the smallest
factor, but instead finds factors comprised of lots of
small factors, and can therefore miss smaller factors which
does not have lots of small factors...  

In this case... the database would not necessarily have the
smallest factor for every exponent with a factor found... but
instead the smallest KNOWN factor... which is not necessarily
the smallest factor for that exponent...

Eric


_
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Re: Mersenne: M727 factored!

[Eric Hahn]

George Woltman wrote:
>>M727, the smallest Mersenne number with no known factor, is done.
>>(It was clearly out of reach of ecm.)
>>
>>--- Start of forwarded message ---
>>From: Peter-Lawrence.Montgomery
>>Date: Thu, 30 Aug 2001 03:26:19 GMT
>>
>>C(2,727-)
>>* c219 = prp98.prp128.SNFSDodson/AKL/CWI
>>* Penultimate prime champion
>>* Runner-up for SNFS difficulty
>> 
>>17606291711815434037934881872331611670777491166445300472749449436575622328
171096762265466521858927
>> 
>>40099499726183758517891939428601665707063794593443940689888526556802581529
262728143398959743444150539520890742947533452401
>>--- End of forwarded message ---


This result does not surprise ME in the least...  Anybody on
the list that saw my post back in July of last year... knows
that from the statistcal anaylsis that was done at that
time...  I posted the following for M727:

 M727 - 94.3716% probability - 2 factors
 M727 - 52.8693% probability - 3 factors
 M727 -  6.0014% probability - 4+ factors
 M727 - 91.1834% probability - 313-bit min. factor size
 M727 - 93.0447% probability - 428-bit max. factor size
 M727 - 21.7336% probability - highly composite factors

Now we know that M727 has 2 factors... and the factors are
326 and 426 bits in length, respectively...  Preliminary
testing also shows that ( factor - 1 ) is NOT highly
composite (having many, many factors)...

Would anybody care to verify the data I posted back then
for M751 

 M751 - 83.8467% probability - 2 factors
 M751 - 74.2974% probability - 3 factors
 M751 - 19.5801% probability - 4+ factors
 M751 - 87.2999% probability - 281-bit min. factor size
 M751 - 81.0003% probability - 526-bit max. factor size
 M751 - 30.1716% probability - highly composite factors

Eric


_
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Re: Mersenne: Factoring on a P4

[Eric Hahn]

Bradford J. Brown wrote:
>For some reason, I am at a loss to explain, a v21  P4 1.4 GHz
>factors significantely slower that a P3 v20 700MHz.  Is there a
>reason, and solution, for this?

Hmmm... Good question...

AFAIK, the only change George has or is going to make in the 
factoring code since v19... is to change the Athlon over to
use the P2/P3 code path... instead of the 486 code path...
Doing such will allow Athlons to trial-factor 2.5-3x faster...
There really isn't a whole lot more speed increase that can
be gained from the factoring code as a whole, AFAIK...

You will also notice a BIG speed decrease with trial-factoring
on ANY machine as you move from factoring up to 2^62... to
factoring up to 2^64... to factoring above 2^64...  This is
expected with the extra instructions necessary to handle the
larger trial-factor sizes...

Eric



_
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Re: Mersenne: Prime95 - V21.1.1 aka v21a

[Eric Hahn]

George Woltman wrote:
>Some Athlons are seeing a speed increase others are not.   The
>two that I know are not enjoying a speed increase are running
>under Win2K.  Maybe there is a bug in the way v21.1 determines
>if prefetch is supported.
>
>For those Athlon owners that are not seeing a speed boost, try setting
> CpuSupportsPrefetch=1
>in local.ini

  This is a possibility.  The other possibility is that there
might be something in Windows that is interfering.

  The reason I say this, is that I have a P3 running at 733Mhz,
and after a reboot, Prime95 was back to running at the same
iteration time before v21 starting running.  After stopping 
Prime95 and adding the line to local.ini, it was back to the
increased speed.  

  Interesting... to say the least...

Eric

P.S. BTW, this P3 is running Win98SE...


_
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Mersenne: Prime95 - V21.1.1 aka v21a

[Eric Hahn]

Hi All,

  I downloaded and ran the new v21a and did some timings on
several different machines and compared them to timings done
on v19 and v20...

  I ran the timings on each version for 100 screen outputs at
100 iterations per screen output...  for a total of 1
iterations...  and then averaged the iteration times...  I
used the same exponent on all versions and machines...  (an
exponent I am primality testing that is just shy of 11,400,000)

  What I can up with was these results...

   V19V20V21
  -  -  -
PII at 266Mhz 0.579  0.578  0.586
Celeron 1 at 466Mhz   0.605  0.604  0.615
Celeron 2 at 550Mhz   0.289  0.288  0.223
P3 at 733Mhz  0.239  0.238  0.188
Athlon at 1333Mhz 0.100  0.098  0.077

  Admittedly, while the 466Mhz Celeron 1 has almost double what
the iteration time was expected to be... (for some yet unknown
reason -- Prime95 is getting 98.9% of the CPU time)...  the %
increase/decrease is still evident

  Note also that the Athlon *did* have a performance increase
on par with the Celeron 2 and P3 machines

Eric


_
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Mersenne: ECM Question...

[Eric Hahn]

  I think I know the answer to this question, but am asking it...
just to make sure...

  According to ECMNet, to find factors of up to 25 digits, the
optimal B1 is 50,000 with 300 expected curves...  and to find
factors of up to 30 digits the optimal B1 is 250,000 with 700
expected curves...

  If a person runs an ECM test using a B1 of 250,000 with 700
curves (for up to 30 digits), will they also find any factors
that they would have found if they had used a B1 of 50,000 with
300 curves (for up to 25 digits) ?!?  

Eric

  I'm presuming the answer is yes... and it works the same for
each level... (1,000,000 with 1800 expected curves for up to 35
digits, etc.)...


_
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Mersenne: Missing Exponents ?!?!?

[Eric Hahn]

  Did anybody else notice that the exponents in the range
between 33,250,000 and 33,300,000 aren't being offered up
by the PrimeNet server ?!?!?That a whole 1328 exponents
that doesn't even seem to be available for tssting

  The assigned exponents report shows the assignments jumping
from 33,249,991 to 33,300,011...

Eric


_
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Mersenne: Companies form Distributed Computing Alliance

[Eric Hahn]

Hewlett-Packard, Compaq Computer and SGI have joined with
distributed computing software seller Platform Computing and
a host of other companies to standardize the way computers are
harnessed into distributed computing collections

Full story at:
http://news.cnet.com/news/0-1003-200-3586486.html

Eric


_
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.exu.ilstu.edu/mersenne/faq-mers.txt

Re: Mersenne: P-1 Credit

[Eric Hahn]

Terry S. Arnold wrote:
>Does anyone have any skinny on when we will start getting credit for
>1.  doing P-1 testing?
>2.  finding a factor during P-1 testing?

AFAIK, from what George has said, credit will eventually be given
after BOTH v21 comes out, and the Scott has time to do some 
modifications to the PrimeNet server...  Time Frame?  ...??...

Eric



_
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.exu.ilstu.edu/mersenne/faq-mers.txt

Re: Mersenne: CPU Time Credit Calculation

[Eric Hahn]

Marc Getty wrote:
>
>How does the CPU time contributed get calculated? I would assume
>that there is a standard credit for each FFT size, but I can't
>find what that credit is anywhere on mersenne.org. 

Actually, the formula isn't based on FFT size.  To get a good
estimate of how much time you'll get credited for any given
exponent, you'll need to multiply the exponent minus 1 by the
average time it takes to do each iteration.  Then multiply
by the number of times faster the PC is than a P-90.  Finally
the % of a year you get is the approx. amount of time credited.

For example: 
  On the exponent 5,593,943...
  Multiply 5,593,942 by .275 to get 1,538,334 seconds.
  Multiply 1,538,334 by 3.5 (for a PII-266) to get 5,384,169 secs.
  5,384,169 seconds is 17.073% of a year...
  So you'll get approx 0.171 P-90 years credit

>I doubt that anyone out there is using more then a 1792 K FFT.

Well  There are actually a few of us brave souls out there
who are QA'ing exponents in FFT sizes all the way up to 4096K!!
Based on my estimates, the exponent I'm QA'ing will provide me
with ~36.348 P-90 years of credit when completed.

Eric


_
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.exu.ilstu.edu/mersenne/faq-mers.txt

Re: Mersenne: Re: Top Producers

[Eric Hahn]

Just an additional note to my last message...  Here's what I found
from a couple of top producers reports around the time:

Top Producers Report 22 Jan 2000 05:01 (Jan 21 2000  9:01PM Pacific)
  86.  challenge  36.031469 1.579106323.64

Top Producers Report 19 Feb 2000 02:01 (Feb 18 2000  6:01PM Pacific)
   1.  challenge 744.487626   125.040   3848   7282.07

And currently:
Top Producers Report 22 Aug 2000 22:01 (Aug 22 2000  3:01PM Pacific)
   3.  challenge 745.440   7630   125.040   3848   6189.45

Notice how much the CPU hrs/day has fallen since...

Eric


_
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.exu.ilstu.edu/mersenne/faq-mers.txt

Re: Mersenne: Re: Top Producers

[Eric Hahn]

Gordon Spence wrote:
>I went to check my account just on the entropia web-sites
>individual accounts report page. The default userid is challenge,
>I just hit enter without thinking and this is the report

>[...SNIP...]

>Can somebody, anybody, please explain how 1 cpu @ 500 and 1 @448 can 
>possibly equal 6194 hours per day

Likely from the fact that around the first of February, all of
the old, defunct ("dead") accounts without activity for a year
or so were merged into the 'Challenge' account.  A message was
posted on the list regarding the action from Scott), with the
"Hopefully nobody will mind" message.  There were no protests
as far as I recall...  

In fact, here's the message (which I just found!):


Reply-To: <[EMAIL PROTECTED]>
From: "Scott Kurowski" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Subject: Mersenne: PrimeNet Top Producers List
Date: Tue, 8 Feb 2000 23:40:57 -0800

Hi all,

Following the database synchro we performed on PrimeNet yesterday,
we cleaned up some of the 'dead' user accounts over a year old.
The cumulative machine times were added to the Entropia.com, Inc.
'challenge' account, the first one opened on PrimeNet in April
1997.  Hopefully nobody will mind our reclaiming the fragmented
time.  :-)

regards,
scott

[EMAIL PROTECTED]



_
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.exu.ilstu.edu/mersenne/faq-mers.txt

Mersenne: P-1 Database

[Eric Hahn]

Wanted: Brave Souls
Re: P-1 Testing small exponents

Besides exponents in the 200,000 - 500,000 range that are available,
new ranges in the 751 - 100,000 are now available!

Note, however, the smallest exponents have been tested to some
degree already.  As a result, they will take a good degree of
time to test.  Some save files are available though!

If you're interested in P-1 testing some small exponents, let
me know.  For exponents under 30,000, bounds of at least
B1 => 1E8 (100M) and B2 => 4E12 (4B) are requested...

Eric


_
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.exu.ilstu.edu/mersenne/faq-mers.txt

Re: Mersenne: Credit for factors found using P-1 tests

[Eric Hahn]

Terry S. Arnold wrote:
>I don't appear to have gotten credit for a factor found with P-1.
>What is the procedure for getting credit for a factor found during
>P-1 testing as part of Double checking?

Currently, PrimeNet does not provide credit for P-1 factoring.  
As I recall, George has said v21 will support it, but there will
have to be some modifications to the server to allow the crediting
to occur...

Eric


_
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.exu.ilstu.edu/mersenne/faq-mers.txt

Mersenne: Better late then never?

[Eric Hahn]

Hi! All,

  I apologize if some of the following message are a little late,
but I've been "out of commission" recently.  At least they're
better late than never

Eric


_
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.exu.ilstu.edu/mersenne/faq-mers.txt

Mersenne: And the winner is....

[Eric Hahn]

RE: Statistical Analysis of Prime Exponent Mersennes

After much private debate, I'm providing the following I have
inquired and received information about.  Please, don't flame
me or ask me to explain further, as I'm only the messenger and
don't have all the answers myself...

Q: Can all the data be posted to the list?
A: HA! Not likely.  The current size of 1.43TB of "raw" data
   which must be "interpreted" (taking 25+ times the space)
   is too large.  I don't know about others, but I don't have
   the 20+ years to download the data over a 56K modem if 
   posted to the list...

Q: What algorithms are used?
A: 'A variety of standard algorithms and methodologies used
   in traditional and non-traditional statistical analyses.
   Used in large number of complex, unique and even 'unusual'
   relations.'

Q: Is the code and/or program available?
A: 'No. Major chunks of code are proprietary, licensed,
   patented [or pending] or 'otherwise' restricted from
   distribution. Typical PC unable to run; Lack of memory
   or storage.'

Q: Can you provide data on M727, M751, M#39, M#40, M*10M-digit?
A: 'Here is info.'

ACTUAL (REAL-LIFE INTERPRETED) DATA:

 M727 - 94.3716% probability - 2 factors
 M727 - 52.8693% probability - 3 factors
 M727 -  6.0014% probability - 4+ factors
 M727 - 91.1834% probability - 313-bit min. factor size
 M727 - 93.0447% probability - 428-bit max. factor size
 M727 - 21.7336% probability - highly composite factors

 M751 - 83.8467% probability - 2 factors
 M751 - 74.2974% probability - 3 factors
 M751 - 19.5801% probability - 4+ factors
 M751 - 87.2999% probability - 281-bit min. factor size
 M751 - 81.0003% probability - 526-bit max. factor size
 M751 - 30.1716% probability - highly composite factors

 M#39 - 53.7390% probability - range=10987349-11013853
 M#39 - 64.0127% probability - range=10914203-11092621
 M#39 - 81.6073% probability - range=10793527-11204183
 M#39 - 97.3391% probability - range=10526447-11390453

 M#40 - 61.4726% probability - range=13430227-13501387
 M#40 - 77.3902% probability - range=13359163-13592549
 M#40 - 86.0715% probability - range=13231913-13684399
 M#40 - 96.5507% probability - range=13092361-13973117

 M#43 - 58.3097% probability - range=41976841-42057331
 M#43 - 71.6352% probability - range=41901683-42138559
 M#43 - 79.7464% probability - range=41753977-42302809
 M#43 - 93.4218% probability - range=41564021-42516373

NOTE: Highly composite means 6 or more factors of the
  factor - 1...

Eric


_
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.exu.ilstu.edu/mersenne/faq-mers.txt

Mersenne: Rambus Memory

[Eric Hahn]

Intel benchmarks show little advantage to Rambus!

A new series of benchmarks have emerged that show Rambus memory
provides less oomph than cheaper, standard high-speed memory.

And the odd part is that the tests come from Intel, the major
proponent of Rambus. 

In benchmark tests conducted by Intel, computers equipped with
standard high-speed memory and Intel's 815 chipset outperformed
similarly configured PCs with Rambus memory and the corresponding
820 chipset from the company. 

Full story at: http://news.cnet.com/news/0-1003-200-2242968.html


[EMAIL PROTECTED] wrote:
<< Direct RDRAM >>

Everyone knows (rather, should know) that RDRAM memory
>provides a minor speed boost compared to SDRAM, and the much
>higher cost of RDRAM is completely unjustified.  I've heard that
>Dell is switching back to SDRAM in its computers now, which is a
>Good Thing(TM).


_
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.exu.ilstu.edu/mersenne/faq-mers.txt

Re: Mersenne: Exponents Already Factored To 64 Bits

[Eric Hahn]

Stefan Struiker wrote:
>I noticed several factoring assignments, in the M13.4 mill range,
>where factoring was taken to only 64 bits, but not to 65, as would
>be done on a "fresh" candidate.  Are these die-hards from the early
>daze when machines were wicked slower?  Or is there another 
>explanation?

Could be that they're using v18...  v19 changed the factoring
depth limits.  Previously, Prime95 would factor to 64-bits up
to 20.4 million range.

Eric


_
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Re: Mersenne: Synchronization

[Eric Hahn]

Stefan Struiker wrote:
>Hi All:
>
>What is a "synchronization" and where can I find out more
>about it?

A database synchronization is when George takes the data in his
database and the data in PrimeNet's database and "causes" them
to be "similar".  

Imagine it akin to making sure the data on both your desktop and
laptop are the same, so when you're working on the data on the
laptop, which you've "synced" with the desktop (which you usually
work on the data on), you've got the right (and up-to-date) data
to work on...

I must agree tho, I think a database synchronization would be
useful.  The cleared exponent report is about 1MB greater
than the assigned exponent report, and I've *never* seen it
be larger...

George?!?  Do you have some free time to do a sync?!?



_
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Re: Mersenne: Browser Quick Stats Tip ... broke

[Eric Hahn]

Siegmar Szlavik wrote:
>> Near the bottom of http://mersenne.org/ips/tops.shtml
>> is a "Browser Quick Stats Tip" that is...
>> http://mersenne.org/cgi-bin/primenet_user.pl?UserID=youraccountID
>>
>> When I use this link, after replacing my account id, I
>> consistently get a blank page returned.  This problem
>> started happening about the time of the server's move
>> south a couple of weeks ago.
>
>same problems here :( two or three weeks ago the link worked
>sometimes, but since then again, nothing but a blank page.

Lately, the link has been working...  However, the top producers
report must have been updated on the most recent hour for it to
work!  The last several weeks, it hasn't been updated
automatically every hour (more like every couple of days)...
If it hasn't been updated on the most recent hour, you may get
a blank page or a "document contains no data" message...  

Eric 'the voice of *plenty* of experience'...


_
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Mersenne: P-1 Database

[Eric Hahn]

Hello! All,

 I've updated the P-1 database again, adding two new lists.
There are now four lists available:
  1)  The entire database (includes *all* tested exponents)
  2)  Tested prime exponents with no known factors
  3)  Tested prime exponents with at least one known factor
  4)  Tested composite exponents
NOTE: Exponents with a factor found by P-1 are not listed if
  I don't know the bounds used for them.

In addition, the exponent range between 200,000 - 500,000 is
now available for reservations for further (deeper) testing...

May the search be with you...

Eric

P-1 Database:   http://mersenne.wackye.com
http://www.mcn.org/2/ehahn/mersenne/


_
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Re: Mersenne: Factoring Assignments: Are They Always "First-Time?"

[Eric Hahn]

Jeff Woods wrote:
>>being found.  Currently, all exponents thru Prime95's limit of
>>79.3M have been factored to at least 2^50...  If a factor is
>>found for an exponent, it's eliminated from further testing
>>of any kind.
>
>Isn't the factor itself verified?

Yes, it is.  However, at least in the case of Prime95, George
has written the code such that the factor is validated before
it's even displayed as a being a factor and written to the
results file.  If it's invalid, the code continues as if
the "factor" was never found...

Eric




_
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Re: Mersenne: Factoring Assignments: Are They Always "First-Time?"

[Eric Hahn]

Stefan Struiker wrote:
>When a requested factoring assignment is listed with, say, 52 in
>an account log, does this mean it has been factored to 52 bits,
>but  _without_ success?  Or could a factor have already been
>found in some cases, but less than 52 bits long?

If it's listed as 52 in the fact-bits column of the report, it
means that it's been trial-factored thru 2^52 without any factors
being found.  Currently, all exponents thru Prime95's limit of
79.3M have been factored to at least 2^50...  If a factor is
found for an exponent, it's eliminated from further testing
of any kind.

Eric


_
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Re: Mersenne: Desperately Seeking Faster Iron

[Eric Hahn]

Stefan Struiker wrote:
>With first-time L-L checking sliding toward a lunar month on an
>"old" 1GHz Athlon, we wonder how the Willamette and Itanium might
>further The Cause.  Anyone have guessimates on the numbers for
>these two, say at 1GHz?

I'd guessimate about 17.5-18 days for an exponent around
10,000,000, for the first Willamette(s) which is supposed
to debut at 1.4GHz...

Then again, according to my calcs, a 1GHz Athlon should finish
the same exponent in about 17.5-18 days...

Go figure!

Eric


_
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Mersenne: Common practice for P-1 math?

[Eric Hahn]

Greetings all,

  I was wondering if it was common practice (ie: the norm) for
P-1 to take the product of two or more factors when giving out
a found factor, if two of more factors are found?

  To clarify, I was curious about how P-1 would indicate more
than one factor being found.  So, I took M113 and fed it into
Prime95 with the bounds of B1=200, B2=2.  Prime95 notified
me that P-1 had found a factor in Stage #1, and that the factor
was 9734174361238150513.  This factors out to 3391 * 23279 *
65993 * 1868569, all of which are known factors of M113.

  Again, is this the norm for P-1?

Eric


_
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Re: Mersenne: Account inconsistency

[Eric Hahn]

Nathan Russell wrote:
>>Can anyone explain this inconsistency in what the server
>>believes the MSRC account has done?
>
>I have a hunch, but it could be wrong.  If a double-checker
>found one of your results wrong, you would have lost credit
>for that exponent.  However, the report might still list it,
>since it should by all means count towards your total number
>of exponents *processed*.

Actually, I suspect it's that results have been turned in, and 
that the account report was "grabbed", since the last top
producers report update.  The server hasn't updated it since
07 Jun 2000 19:01 (Jun 7 2000 12:01PM Pacific)
I've experienced similar situations in the past when the server
doesn't update a report every hour as expected, and the report
remains unchanged for a day or two as a result...
BTW, the server not updating a report every hour has been
happening quite frequently lately... :(  

Eric

P.S. The partial top producer lists don't update even if the full
length report does.  But I believe it's because the screwy nature
of the full length report.  If you want to see what I meen, take
a look at the full length top producers list.  It begins like...

Mersenne PrimeNet Server 4.0 (Build 4.0.031)
Top Producers Report 08 Jun 2000 22:01 (Jun  8 2000  3:01PM Pacific)

This report is updated every 60 minutes
 
RankAccount IDLL P90*  Exponents Fact.P90 Exponents P90 CPU
  CPU yrs  LL Tested CPU yrs* w/ Factor hrs/day
--    ---  -  - 
.  curtisc3175 8
.  challenge  7630  3848
.  SW 380737
.  TempleU-CAS272934
.  vidmar 174420
[...rest of list...]


_
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Re: Mersenne: Manual Testing Forms Still "Broken"

[Eric Hahn]

Stefan Struiker wrote:
>To All:
>
>In the server transition, the Manual Testing Forms still
>seem to be broken.  Can't UNreserve exponents, for example.

Hmmm  The manual tests page does appear to post to entropia.com
by default. :(   One hack around this (until the page is changed)
is to save the file to disk, load it into a text editor, find the
lines that start with:
  http://entropia.com/cgi-bin/
change these lines to:
  http://mersenne.org/cgi-bin/
Save the file back to disk.  Afterwards, load the file back into
your browser *from disk*, and fill in the appropriate manual test
boxes.  Clicking on the "submit" buttons should then perform the
task desired correctly.
NOTE: Once saved and changed on disk, you don't have to redo the
procedure all over again. You can instead just load the previously
saved file on disk!

On a side not, the thing that bothers me most about the whole
thing though, is that no warning came of the time/date the
switch would be made, leaving people completely in the dark.
You only got a "Page Not Found" error when you attempted to get
your info.  As I recall, something was said about a warning
being issued first the next time something like that was going
to happen...

Eric


_
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Re: Mersenne: Entropia Servers

[Eric Hahn]

Levi Broderick wrote:
>Yeah.. I kinda also noticed that the entropia.com servers have
>been wacky today.  Something strange, though -- I was playing
>around with URL's and this can get you your account information:
>
>http://www.mersenne.org/cgi-bin/primenet_report.pl?UserID=*HIDDEN*&UserPW=*
HIDDEN*
>(http://mersenne.org/ips/accounts.html)

Ah!  So it appears that the transition of the cgi(s) from
Entropia.com to Mersenne.org have finally been made  I
had understand this would eventually happen.

>Kinda surprised that this info was up on the mersenne server;
>I always thought it and the entropia servers were located
>separately.  Oh well, for those of you who wanted to check
>your account info, here's at least a temporary solution. :)

As I recall, George had posted something several months ago
about entropia.com hosting the GIMPS domain (mersenne.org) from
that point on.  I also remember something about a transition
of the PrimeNet server from the Entropia to the Mersenne domain.
As of 2 or 3 weeks ago, everything had seemed to be moved over
expect the cgi(s). (As of last Friday, the URL(s) requiring
cgi (including the one above) did not work if they pointed to
mersenne.org)

>From what it appears you must now have mersenne.org instead of
entropia.com in *any* URLs that point to the PrimeNet server for
complete access.

Eric


_
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Mersenne: Online P-1 Database

[Eric Hahn]

Greetings all,

  I've made a few modifications to the P-1 database webpages.
  
  In addition, I'm providing a new address for it, since some
people have been having trouble accessing it.
  For those who would like a short address:

  http://mersenne.wackye.com

  For those who've been having trouble, the long address:

  http://www.mcn.org/2/ehahn/mersenne/mersenne.html

Eric


_
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Mersenne: Clarification on M#39, M#40, M727...

[Eric Hahn]

Greetings all,

  From the responses I've gotten, I suppose I've confused most
people, or left them in the dark :(  I guess I thought the
subject would explain most things

  First, for those who've asked the question, I'm not storing
the 1TB or so of data personally, which is part of the reason
I need to know some ideas, etc. on what to post, if anything.
I'll need to request the specific data desired...

  Second, the type of information I've received concerning the
statistical data I've received (and is contained in the data),
is of a statistical probability nature. For example(s):
  M14,989,627 has a 93.42% probability of having a 53-bit factor.
  M14,999,953 has a 9.31% probability of having a 53-bit factor.

  M101 has a 89.17% probability of having 2 factors.
  M101 has a 73.25% probability of having highly compositable factors.

  M113 has a 92.36% probability of having 5 factors.
  M113 has a 64.03% probability of having highly compositable factors.

  There is a 81.62% probability of a Mersenne Prime between
M6,957,583 and M7,001,681
  There is a 84.17% probability of a Mersenne Prime between
M6,923,117 and M7,005,181
  There is a 93.01% probability of a Mersenne Prime between
M6,898,967 and M7,018,511

NOTE: These are just examples that I've come up with to give an
idea of the nature of the data (which I used previously known
information to create).  I don't even know if the data is stored
in such a manner or is interpreted to this manner...

  Since these are statistical probablilities, I can't even 
guarantee the accuracy of the data.  However, in a test run
that was made to validate the data (not by me, mind you),
approx. 436 exponents that had high probability to have a
53- or 54-bit factor was tested and 401 had a 53- or 54-bit
factor found!  There's no telling how many exponents in the
range tested have a factor of this size which wasn't tested
due to a lower probability...

  One last thing... The data is based on current information
as of 4-6 weeks ago, some of which may have changed.  It
"predicts" information that isn't known as of that date, such as
# of factors in M727 and M751, range where M#39 and M#40 is,
etc. (which was why I had the subject I did).

  If anybody has further questions or is still confused, let
me know and I'll try to clarify some more...

  Again, the ideas, suggestions, comments, etc. I'm looking for
covers these areas and ???:
1)  Should I post a *tiny* fragment of this information?
2)  What information should I post, if I do?
3)  Would it be beneficial to the overall effort?
4)  Would it divert resources that could be used better otherwise?
5)  Could it cause problems with regard to that "p" hunting term?
6)  Anything else??

Eric


_
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Mersenne: M#39, M#40, M727, M751, et al.

[Eric Hahn]

Greetings all,

  I need some ideas, suggestions, comments, recommendations, etc.,
either in private or on the list (for discussion purposes only,
so as not to overload the list).

  I've received information back on some statistical data after
a long, grueling analysis of Mersenne data.  There is tons upon
tons of data from this anaylsis, much more than I could ever
possibly handle, more or less receive (at least 100 DVDs worth
of data -- compressed!)

  Here's what I'm looking for:
1)  Should I post a *tiny* fragment of this information?
2)  What information should I post, if I do?
3)  Would it be beneficial to the overall effort?
4)  Would it divert resources that could be used better otherwise?
5)  Could it cause problems with regard to that "p" hunting term?
6)  Anything else??

Eric Hahn

P.S.  I deeply thank Sarah Wright and Mark Burke for their
contribution of time, effort, and resources, as well as their
continued effort in this endeavor...  Without them, this and
further analysis would not be possible!!



_
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Mersenne: P-1 Database is online!

[Eric Hahn]

Greetings all,

  The first iteration of the P-1 Factoring database is now online!
It still has some work to be done, including (but not limited to)
collecting, sorting through, and merging a lot of information for exponents
< 1,000,000, and separating the list into two (one for exponents without
any known factors, one for exponents with at least one known factor).

  The address to find it at is:  http://mersenne.wackye.com

Eric


_
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Mersenne: $7 Million in prizes

[Eric Hahn]

Hi!

  This is a little off-topic (not completely tho), and thought
that I few of you might be interested in this...

  The Clay Mathematics Institute is offering $7 Million in
prize money to anybody who can provide solutions to any of
their 7 Millenium Prize problems ($1 Million for each problem).
The problems are considered to be the hardest and greatest
unresolved mathematical problems of the 20th century.
  They include:
  P versus NP
  The Hodge Conjecture
  The Poincaré Conjecture
  The Riemann Hypothesis*
  Yang-Mills Existence and Mass Gap
  Navier-Stokes Existence and Smoothness
  The Birch and Swinnerton-Dyer Conjecture
 *This one deals with prime numbers and is on-topic...

  You can find out more at their website: http://www.claymath.org

Eric


_
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Mersenne: P-1 Database

[Eric Hahn]

Greetings all,

  Well, the response to the P-1 database has been overwhelming...
I received over a dozen respones with 2 hours of posting the
request to the list...

  I'm still in the process of collecting and merging data into
the database.  However, I hope to have the first batch of
data available on the Web by the end of the week!!

  In the meantime, I've run across a scenario for which I need
some information confirmed.  Not being a mathematician, and
only knowing a general overview of P-1 testing, I want to
verify my understading before I proceed witht he situation...

  I've run across a number of exponents that have been tested
multiple (>1) times AND meet a special situation.  The bounds
for one test have a higher B1, but lower B2, then another.
As an example (no specific case exists *yet*!):
  B1 Bound  B2 Bound
    
Test #1: 1  1000
Test #2: 25000   250
Test #3:10   500
Test #4: 5   750

  I assume that I would use both the B1 and B2 from test #3,
as it has the highest B1 bound.  I'm assuming this since we
want all the factors of k (from 2kp+1) to be less than B1 OR
all less the B1 except one which is between B1 and B2.  As a
result, the B2 bound is B1 dependent...

  Correct?  Wrong?  Let me know so I can add these special
exponents to the database...

Thanks,

Eric


_
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Mersenne: Mersenne P-1 Database

[Eric Hahn]

Calling all P-1 factorers,

  I'm in the process of creating a database of P-1 factoring
data for all Mersenne numbers.  I have not found any other
database for this information available on the 'net.  There
is some data kept by Will that's available, but it only goes
to M(169,991)...

  I am collecting data for unfactored Mersennes presently,
but this may expand -- depending on size of the database --
to include all Mersenne numbers not completely factored...

  If you're interested in seeing this database get started,
and of making use of it, please send me your data.

  I need the exponent, B1 bound, and B2 bound.  You can
send the a results file if that's the easiest...

Eric


_
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Re: Mersenne: The recent popularity of Single-Checking

[Eric Hahn]

Nathan Russell wrote:
>There is a user, "sd70045", who has almost 100 single-checking
>assignments out on a single machine ID.  These would take a
>state-of-the-art box well over two years to finish.  Additionally,
>these assignments have almost identical figures for time to
>complete etc.  The first exponent in this group is 8936071; the
>others are directly below it.

I examined this, and found out that there is actually 197
assignments checked out to this individual (188 to the same
machine ID (7 dbl-chks, 5 factoring, 176 L-L tests)).  By
my estimates, this single machine ID has >5 yrs worth of work
for even the faster state-of-the-art PC.  While they have
various run times, they all have 16 days to go and 16 days
until expiration... They all were also updated on the same
date and time (10-Feb-00 17:55).  None appear to have had
any work performed on them at all!!

While I normally might think this might be a person switching
over to use PrimeNet from previously not using it, and possibly
using a large cluster (using the same ID for the entire cluster),
there are a few indications this isn't the case.  First, their
ranking on PrimeNet is 8112 and 2323 for primality testing and
factoring respectively, and their P-90 CPU hrs/day at 13.79.
Second, their ranking on George's list is 6800 (with only one
additional exponent tested above PrimeNet's count).  Finally,
they have 6 other machines that actually appear to be performing
some kind of work.

In any case, these exponents will expire in 16 days.  As a
result, I'm not concerned about it.  Within 3 weeks
they'll be re-circulated among other users.  The only thing
that would cause concern, is if the user intentionally updates
these exponents in the next two weeks...


Eric


_
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Re: Mersenne: Where's the script?

[Eric Hahn]

Mark wrote:
>A while ago we were discussing about a Java / JavaScript thing
>to put on the Mersenne page.  I'm wondering if it's up yet, and
>if so, where it is.

Yes, it is up.  George modified a javascript module I wrote and
put it into the benchmark page at the following address:
http://www.mersenne.org/bench.htm
It calculates the *estimated* time to perform a L-L test based
on CPU Type/Speed/Hours and the exponent...

>Also, I'm wondering if anyone can tell me
>how many digit's a certain exponent has.   
>Thanks!

Divide the exponent by 3.32192809488 and round DOWN to the
nearest whole integer to get the number of digits...

Eric


_
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

RE: Mersenne: time needed for factoring

[Eric Hahn]

Aaron Blosser wrote:
>>Henk Stokhorst wrote:
>>>L.S.,
>>>
>>>Just curious, what makes factoring 13.388.659 take four times as
>>>long as 13.375.793?
>>
>>It's because 13,388,659 is past the cutoff of 13,380,000 where
>>Prime95 starts factoring to the depth of 2^65 instead of 2^64.
>>Normally, increasing the depth by a factor of one only doubles
>>the time required.  However, because of the nature of chip
>>architecture, it
>>takes a longer period of time than normal
>>above 2^62 and again above 2^64 to do the necessary
>>calculations (more instructions and such).
>
>Now, I may be totally off base here, but...
>
>The reason is because the integer part of the Intel CPU is 64
>bit...okay, so Prime95 does some additional steps to provide
>greater bit depth factoring...
>
>Now, if that's really the case, would it be of any advantage
>to have the FPU handle factoring?  I know that some processors
>only do factoring because they have a slow FPU to begin with
>(like Cyrix and AMD K6 chips), but would a Pentium be able to
>use it's FPU to do trial-factoring to greater bit depths any
>faster than the software based solution George uses beyond 64
>bits?

Actually, George uses the FPU for trial-factoring.  The problem
is that even the FPU is only 80 bits (IEEE standard).  Factors
up to 2^64 can get the results in one stage (64-bits), however
you have to take extra steps to get any additional bits above
that up to 2^76 where Prime95's limit is (64-bits + 12-bits)
This means it takes one stage to get the first 64 bits of a
result and another stage to get the remaining bits

>Better yet, do any of the wacky  SIMD/MMX/3DNow instructions
>provide any possible benefits for trial factoring?  I recall a
>discussion before about how those instructions wouldn't be too
>useful for LL testing because of they only handle double-word
>sized data (32 bits), but for trial-factoring...any uses?

Personally, I doubt it would benefit any, but I could be wrong...

Eric 


_
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Re: Mersenne: time needed for factoring

[Eric Hahn]

Henk Stokhorst wrote:
>L.S.,
>
>Just curious, what makes factoring 13.388.659 take four times as
>long as 13.375.793?

It's because 13,388,659 is past the cutoff of 13,380,000 where
Prime95 starts factoring to the depth of 2^65 instead of 2^64.
Normally, increasing the depth by a factor of one only doubles
the time required.  However, because of the nature of chip architecture, it
takes a longer period of time than normal
above 2^62 and again above 2^64 to do the necessary 
calculations (more instructions and such).

Eric


_
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Re: Mersenne: Milestones?

[Eric Hahn]

Let me rephrase something from my last message:

There should be 12 non-Primenet exponents left to finish testing
(if they aren't already) to prove both M(2976221) and M(3021377)
are the 36th and 37th Mersenne primes, respectively...

Eric


_
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Re: Mersenne: Milestones?

[Eric Hahn]

Nathan Russell wrote:
>>From: Jeff Woods <[EMAIL PROTECTED]>
>>To: [EMAIL PROTECTED]
>>Subject: Re: Mersenne: Milestones?
>>Date: Tue, 09 May 2000 12:37:31 -0400
>>
>>We still have a handful of exponents to go.
>
>I was looking at the server's assignments out pages.  I guess the 
>assignments in question must be non-PrimeNet.

There are some lower exponents not assigned to PrimeNet, due to
some people who are still using *old* versions of the program.
Based on the figures I have available, there should be 12
exponents left to finish testing (if they haven't been finished
already) not assigned to PrimeNet to prove both prime.  We'll
find out for sure when George updates his database...

>>The official location for these milestones is:
>>
>>http://www.mersenne.org/status.htm
>
>I am aware of that, but IIRC these are updated only every few days.

George has been updating the page once a week, usually on
Wednesday; sometimes on Thursday...

Eric


_
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Mersenne: Re: Problems with Iteration Time Prime 95

[Eric Hahn]

David Hoyle wrote:
>I am running v19.2.1 on a P3/500 and can achieve 0.34 second
>iteration time with Prime running alone. However,  because
>of our dodgy electricity supply out here in the country, I
>have to run the m/c with an APC UPS which has Powerchute
>5.0.1 installed to achieve graceful shutdown if there is a
>protracted power failure. Even despite setting Prime95 to
>priority 9, a program in the UPS suite - ICONCLNT.EXE - takes
>78% to Prime's 17% of the cycles according to Wintop98. Before
>getting in touch with the manufacturer of the UPS system, who
>is not going to see his program as malfunctioning, I thought
>I would check if anyone else in the GIMPS programme has had a
>similar problem and found a way round it. The only things
>taking any signficant resources for the vast proportion of
>the time are Prime 95 and the UPS to ensure the power supply
>integrity is guaranteed. I hope this is not a Catch 22
>situation.

David,

  Good news!!  I ran across the same problem when I first
installed my UPS several years ago.  I *did* call APC and 
was told that ICONCLNT.EXE only manages the icon in the
system tray (that's the *ONLY* thing it does!!).  It you
can live without it (ie: not having the power status of the
UPS always displaying in the system tray), you can get rid
of it.  It will *not* affect the reliability of the UPS in
any way.  The system tray icon is a visual indicator for the
user.  The UPS makes noise when the status changes, so there
isn't any real need for it.

  In Windows 98, go into System Information tool (located
under Programs | Accessories | System Tools.  Select the
Tools menu and then System Configuration Utility.  Click on
the Startup tab.  Find ICONCLNT.EXE in the list, and remove
the check in the box.  Click OK, exit the program, and
restart Windows.  BAM!!  No more system tray icon, Prime95
can get the CPU's time, and the UPS is running fine!!

Eric Hahn


_
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Re: Mersenne: Java/javascript anyone?

[Eric Hahn]

George Woltman wrote:
>   In my new benchmarking page I'd like to create a form that
>takes CPU type, CPU speed, and exponent and returns the estimated
>number of days to complete the exponent.  I hope this will help
>newcomers understand how much effort is required before joining
>GIMPS.
>   Can this be done in Javascript (both MSIE and Netscape)?
>Can it be done on the client side (i.e without a "Submit" button
>and CGI)?
>If so, would someone care to volunteer to write the necessary script
>using three or four lines from the http://www.mersenne.org/bench.htm
>table and I'll fill in the rest?

George,

I've come up with a dynamic javascript form for the purpose.  It
needs a little more work to be done.  I'm converting the numerous
'if' statements into an array lookup, and making it calculate out
more than just days...  I should have it fixed up within two
or three days  I'll send it to you when it's finished to your
opinion at that time!

Eric


_
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Re: Mersenne: 65 bits (was Re: factoring)

[Eric Hahn]

Nathan Russell wrote:
>It will only get worse for the 486 users when PrimeNet begins
>handing out exponents that will need factoring to 65 bits.  Of
>course, they can use factoroveride, but that's not helpful to
>the network as a whole.

However, the factoroverride switch is not designed for use with
the PrimeNet server.  For reasons unknown, the server does not
release the exponent upon report of factoring being done when
using the switch.  That's why there was a complaint a while back
on the list that somebody had several thousand factoring
assignments out.

>For those who don't know, due to CPU design reasons that I
>don't claim to understand, factoring to 65 bits takes easily
>four or five times as long as factoring to 64 bits.  In
>version 19, it was set to take place for exponents 13.38M and
>up.  I believe PrimeNet will reach this point in a few months.
 
While I had calculated it at 4.5 times as long (2x for the same
percentage completion, and 2.25x for the iteration time), I've
been getting ~4.2x as long.  For some reason, IPS assigned me
a couple dozen exponents just above 13.38M, and what would
have normally taken me 38 hrs. for to 2^64, it's been taking
~160 hrs. to do to 2^65...

For comparison sakes, I'll note this:  I've had my system set
up to output once every 60 secs (for 63- and 64-bit factors).
At this point it was getting a % complete of 0.132% every
~59.98 seconds for 2^64 (64-bit factors), and a % complete of
0.066% every ~136.20 seconds for 2^65 (65-bit factors).


Eric 


_
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Re: Mersenne: Re: Facelift (round 2)

[Eric Hahn]

Steinar H. Gunderson wrote:
>On Tue, Apr 18, 2000 at 02:32:01PM -0700, John R Pierce wrote:
>>actually, I believe its done with client side JavaScript.
>
>Anyways, it doesn't work in NS, and NS _invented_ JS ;-)

That's because the way MS wrote the JS...

MS has a variable for the drop-down toolbar menu that's
initialized as false.  They then check to see if the browser
is MSIE, and if it is, changes the variable to true.  If is
isn't, it leaves it as false, and the drop-down toolbar isn't
displayed...

BTW, MS also claims it isn't displayed because of a bug in NS,
which isn't true, since they don't check and change the variable
if NS (or any other browser) is used...

>From MS' JS:

var ToolBar_Supported = false;

if (navigator.userAgent.indexOf("MSIE")!= -1 && 
navigator.userAgent.indexOf("Windows") != -1 && 
navigator.appVersion.substring(0,1) > 3)
{
ToolBar_Supported = true;
}



Eric
_
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Re: Mersenne: M727 has a factor?!?!?

[Eric Hahn]

Will Edgington wrote:
>
>   P-1 on P727 with B1=30, B2=1
>   P727 stage 1 complete. 116 transforms. Time: 0.018 sec.
>(4659194 clocks)
>   Stage 1 GCD complete. Time: 0.001 sec. (164887 clocks)
>   P727 has a factor: 11633
>
> This meets all the criteria too
> 1) 11633 is PRIME.
> 2) 2kp+1 = 2*(8)*727+1 = 11633
> 3) 8n+1 = 8*(1454)+1 = 11633
> 4) 2^p (mod n) = 2^727 (mod 11633) = 1
>
>11633 divides M1454 where 1454 = 2*727, but 11633 does not
>divide M727.  Your #4 calculation has a bug, probably a
>rounding error; the correct result is 11631.

Well, I went back and did it by hand!!  You're right about #4...
BTW, George wrote that what I got was a result of a parsing
error on the part of Prime95 (it did 2^727+1, not 2^727-1).

R = 1
727 = 1011010111
E=727D=1R=2A=4
E=363D=1R=8A=   16
E=181D=1R=  128A=  256
E= 90D=0R=  128A= 7371
E= 45D=1R= 1215A= 5531
E= 22D=0R= 1215A= 8804
E= 11D=1R= 6133A=11370
E=  5D=1R= 4008A=11004
E=  2D=0R= 4008A=  119
E=  1D=1R=11632A= 2528
E=  0*11632*   


Eric


_
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Mersenne: M727 has a factor?!?!?

[Eric Hahn]

Hi!!

  Tell me I'm wrong...  and if not, what happened??

  I just made a slight error in adding a P-1 factor assignment
to the WORKTODO.INI file for M727 and came up with the following
result (on screen):

P-1 on P727 with B1=30, B2=1
P727 stage 1 complete. 116 transforms. Time: 0.018 sec. (4659194 clocks)
Stage 1 GCD complete. Time: 0.001 sec. (164887 clocks)
P727 has a factor: 11633

and in the RESULTS.TXT file:

[Sat Apr 08 10:43:37 2000]
P-1 found a factor in stage #1, B1=30, B2=1.
UID: Net_Force/V20, P727 has a factor: 11633

  This meets all the criteria too
  1) 11633 is PRIME.
  2) 2kp+1 = 2*(8)*727+1 = 11633
  3) 8n+1 = 8*(1454)+1 = 11633
  4) 2^p (mod n) = 2^727 (mod 11633) = 1

Eric

P.S. the error in question was:  Pminus1=727,1E16,0,0,0


_
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Re: Mersenne: How do I start factoring...

[Eric Hahn]

Michael Oates wrote:
>How do I start factoring when I am part way through doing
>an LL test, I would just like to have a break from LL tests
>for a few weeks and do some factoring, but I don't want to
>loose the number I am part way through. 
>
>What is the procedure to use?

There's actually 3 ways you could go about doing this...

1) Request exponents to factor thru the manual testing forms
   at http://www.entropia.com/ips/manualtests.html#checkouts
   and then add them to your WORKTODO.INI file at the beginning
   (stopping PRIME95 first, adding the lines, then continuing).

2) Make sure PRIME95 is set up to request factoring, stop PRIME95,
   edit the WORKTODO.INI file to remove the LL-test, save the
   WORKTODO.INI file, continue PRIME95 and let it contact IPS
   and request some factoring work, stop PRIME95, re-edit the
   WORKTODO.INI file, add the LL-test back at the end, save the 
   WORKTODO.INI file, and continue PRIME95.  NOTE: Cut and Paste
   works best if doing it this way.

3) Start a new instance of PRIME95 doing factoring work.  At
   this point you can either let the new instance run (stopping
   the original instance while the new instance in running), or
   stop both instances, combine the WORKTODO.INI files into the
   original instance's WORKTODO.INI file (having the LL-test at
   the end), and continue on with the original instance of
   PRIME95.

I sure there are probably a couple of other ways too

Eric


_
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Re: Mersenne: Factoring Depths

[Eric Hahn]

Dave Mullen wrote: 
I'd just like to get a clarification on some files I downloaded from the Entropia FTP.
  
Re the file of exponents, and how far they have been trial factored. 
  
I extracted a range using the decomp program. Each exponent has a number by the side, but I am unclear to what this number refers.
  
Is it 
  
a) The bitlength of the K value alone i.e. a bit length of 32 would indicate all K values 1 to (2^32) have been tested ?
  
or
  
b) The bitlength of 2 x K x Exp + 1 as computed ?
  
Just to save me repeating previously done work.
  
The answer is B.  It the length of the actual factor being
tested.  Therefore, 1139,64 means that all potential
factors thru 2^64 (18,446,744,073,709,551,615) have been
tested (all ~10^12 of them).

Eric


_ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers 

Mersenne: RE: information please

[Eric Hahn]

Perhaps somebody with a little more knowledge about these
matters can help this person...

Frank Dull ([EMAIL PROTECTED]) writes:
>i am new to this type of stuff and need some help.  can you please
>point me to some explicit information on the web dealing with the
>different factoring methods?  i hear about trial factoring and ecm
>and p1 and nfs and mpqs and others but am unable to find any
>good information about them.  how do you figure the information
>required for them like bounds and curves and polynomials and such?
>i need it as simple as possible since i can not understand half
>of what i have seen.
>


_
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Mersenne: Re : Odd's on finding a factor

[Eric Hahn]

Dave Mullen wrote:
>Sorry, I'm no mathematician, and new to the Mersenne field.
>  
>> No, in the x-y bit range (remember that n bit integers are
>> about >2^n) the first factor could be x/2 to y/2 bits long
>> (powers of a power >multiply).
>  
>What I was trying to say in my disjointed way was ...
>  
>(Example) M11 = 2047 (11 bits long). Now 2047 has only 2 factors 
>(23 >x 89) and the square root of 2047 is approx 45. 45 is 6 bits
>long, therefore the factor lower than the square root must have
><= 6 bits, >and the factor higher than the square root must have
>>=6 bits.
>
>23. is 5 bits long, and 89 is 7 bits long.
>  
>Thus for the exponent 1165 bits long, if it only has 2 factors , >then the first factor must be between 2 and 3413 bits long, and
>the second factor must be between 3413 and 1164 bits long.
>Note that the bit lengths of the 2 factors added together must
>equal the bit length of the Prime (or bit length of the
>Prime + 1) !!


There only a slight error with your logic...  For the exponent
1165, the root is *not* 3413 bits long, but more like 5825000
bits long.  Perhaps you forgot exponents add, not multiply.

For simplication:
2^3 * 2^3 = 2^6
8  *  8  =  64
Therefore:
2^1165 = 2^5825000 * 2^5825000

Eric Hahn


_ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers 

Re: Mersenne: high factoring bug in prime95

[Eric Hahn]

George Woltman wrote:

>   This is primarily directed at the 4 or 5 users dedicated to
>factoring exponents above 35 million.  Prime95 version 19.1 has a 
>bug that causes it to miss some factors for these large exponents.
>If you are one of the 4 or 5 affected users, please download
>version 19.2 to fix the problem.

One ugly fact about this too... exponents already tested above
35.79M may need to be re-tested!

Within 10 seconds of starting v19.2, two new small factors
were found for exponents already tested and found to have
factors (just not that small)...  Six new smaller factors were
found testing just 24 exponents previously tested that had
factors.  And for exponents that have had no factors found
yet, there might be a smaller one that wasn't discovered :(

Eric Hahn


_
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Re: Mersenne: GIMPS in Dallas Morning News

[Eric Hahn]

Shaun Griffith wrote:
>GIMPS (along with SETI@Home   and everything
>else) made it in the Dallas Morning News in the Person@l 
>  Technology section (print version).
>
>Maybe someone can search the online version at http://www.dallasnews.com/
>for the story (I don't have time this morning).

That address for anybody interested is:

http://www.dallasnews.com/technology/1202ptech9pcs.htm

Eric

_
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Re: Mersenne: Trial-factorers

[Eric Hahn]

Brian Beesley wrote:
>On 27 Oct 99, at 17:23, Eric Hahn wrote:
>> 
>> I'm looking for program(s) capable of trial-factoring 
>> prime exponent Mersenne numbers (using 2kp+1) meeting
>> the following requirements:
>> 
>> [...requirements...]
>
>Well, I'm prepared to have a go. Could we tighten up the spec a bit?

Wow!!  I was going to post a message with regard to the fact
that it looked like I was going to have write some code to 
produce my own program.  While the programs that were suggested
are well written, perform their designed functions, etc., they
were either not capable of the tasks required or too slow to
be useful.  

Now, look.  I even have a volunteer to write some code!!  :)

>(a) There's also been some interest in something else that Prime95 
>doesn't do - trial factoring 2^p+1.
>
>(b) I assume we're only interested in 2kp+1 factors. This means that 
>we will miss any factors which are not of this form. (Applies to 
>Mersenne numbers with composite exponents, and all 2^p+1 numbers - 
>though I believe that the "missed" exponents are easy to derive 
>analytically.)

I'm not opposed or take exception to any possible additional
capabilities...  It just might require a little extra effort
for the coding.

>(c) I presume we're looking for a program optimized for IA32 
>architecture. The mersfac* programs are available but are unlikely to 
>be optimally efficient on any particular hardware platform.

Optimized for IA32 would be beneficial (which processor
architechure runs >80% of PCs?).  If possible, the ability
to modify so as to optimize for other architectures would
be a plus, however.  One big concern is speed though!

>Given that, I suggest limits on exponent < 2^62 and on factor < 2^95
>(these are convenient for the architecture).

After waking up several nights ago with some pretty *scary*
thoughts, I realized a couple of things.

As such, exponents through 2^62 should do fine.  Anything
that might be necessary above 4.6 x 10^18 could probably
be extrapolated (not that I can think of any reason, currently,
that would cause it to be necessary).

Factors, however, would be slightly different.  I suppose 2^95
would be acceptable for a base level (or default), especially
if testing an entire bit depth (or a large range of factors).
However, if testing a small and specific range of K, say
K=2^143 to K=2^143+500, it might need to go considerable
higher.  I'm willing to make a few sacrifices for this to
be possible...  

Admittedly, I'm not "in the loop" regarding the division
of the massive numbers for which I'm talking.  I'm sure
somebody is, however (and maybe could explain it).

>It's probably sensible to go for an application which runs in a "DOS 
>box" rather than a proper windowed application. This makes it a bit 
>easier (for me) to write & also makes deriving a linux variant almost 
>trivial. (Does anyone know for sure whether or not there's a DOS box 
>in "Millenium"? I heard a nasty rumour...)

I heard the same nasty rumor...  Actually, I've heard several,
including ones about the floppy and Win16 support, among others.


Eric


_
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Re: Mersenne: Questions about prime.ini syntax, and hardware advice.

[Eric Hahn]

Albert Garrido wrote:
>I'm currently trying to configure the Time command, as
>listed in the docs, to get the prime95 client to function
>as follows. 
>
>User ID=XYZABC
>Time=1-5/18:00-0:00,1-5/0:00-08:00,6-7/0:00-24:00
>(reset of Prime.ini)

If you're trying to run from Midnight to 6AM and 6PM to
Midnight on Mon-Fri, the time line should read as follows:

Time=1-5/0:00-08:00,1-5/18:00-24:00,6-7/0:00-24:00

Note Midnight is 0:00 when starting the day and 24:00 when
ending it.  It's exactly like what you have for Sat-Sun.
It's also best if you put them in order by time (you'll
notice I switched the two Mon-Fri times around).  There's
not usually any problems, but glitches do happen.

>I don't know if the undocumented commands are being
>supported, or it's been discussed already.  I'm using the 
>prime.ini=yourfilename and local.ini=yourfilename.

Perhaps somebody else can help you here.  They look okay,
but I have never used them myself (no need!)

>I know it's slightly off-topic, but I am in need of advice
>as far as how well Prime will run on this machine.  I
>currently have an order in place for an Kryotech Cool
>Athlon™ 900.
>[...]
>How fast would something like this get through an average LL
>test?  Something in the 10202624 range?  
>[...]

Based on the known information about LL-testing times, 
Prime95 should be able to LL-test a number such as
10,202,623 in 2 to 2.5 weeks.  A 10M digit exponent
could be tested in about 7-8 months

_
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Mersenne: Trial-factorers

[Eric Hahn]

I'm looking for program(s) capable of trial-factoring 
prime exponent Mersenne numbers (using 2kp+1) meeting
the following requirements:

1) Capable of trial-factoring any exponent > 1 
   (at least to some considerably large number,
say 1 trillion?)

As I recall, Brian [Beesley] mentioned something once
about having a program that could test an exponent
of an arbitrary size...  Brian??
   
2) Capable of testing a factor of any size.
   (even over the 2^76 limit of Prime95).

I just know somebody is going to have to mention the
time involved in testing factors of such a large size.
Let me just say, I realize *exactly* how much time
would be required...

3) Capable of trial-factoring a range of k's.
   (example: from k=1000 to k=2500)

It would be best if all three of the requirements
could be fulfilled by a single program...

Can anybody be of some help???

Eric Hahn


_
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Re: Mersenne: Factoring numbers...

[Eric Hahn]

Jukka Santala wrote:
>Is it just me, or does factoring smaller Mersenne numbers take
>propotionally much longer? I would expect M727 to be much faster
>than the 33M range to a fixed depth, yet the opposite _seems_ to
>be true.

For any given factoring bit-depth, larger exponents will take
a shorter period than smaller exponents.  This is due to the
number of potential factors that are available in at any given
depth.  Each bit-depth takes twice the amount of time to test
as the previous one (ie: 2^57 takes 2x the length of 2^56)

To determine the approximate number of potential factors that
must be tested at any given depth, take the bit-size of the
first pontentail factor, 2p+1, and double for each bit-depth up
to the bit-depth you want.  Finally, divide by 2 (eliminating
potentials not meeting the 8n-1 or 8n+1 rule).

So, the first potential factor of 727 would be 1455 (an 11-bit
number).  Take 1 for the number of potential 11-bit factors,
and double over and over until you get where you want (2 
12-bit potentials, 4 13-bit, 8 14-bit, etc.).  However, 
33,219,283's first potential factor is 66,438,567 (a 26-bit
number).  It has 1 26-bit potential, 2 27-bit, 4 28-bit, etc.
Take these numbers and divide by 2 for the numbers of
potential factors that need testing.  You can see how there
are *way* more potential 57-bit factors for 727 than 33,219,283.

NOTE: These figures are approximate as 727 may only have say
3 potential 14-bit factors to test.  (Actually, it only has 2!).
It will give you a good idea of the number of potential factors
you are looking at testing for any given bit-depth though...

To illustrate better: 
  To test the exponent 727 at 2^57 (only 57-bit factors), you
must test approx. 7 x 10^13 potential factors.
  To test the exponent 33,219,283 at 2^57 (only 57-bit factors),
you must only test approx. 2.15 x 10^9 potentail factors.

BTW, there is a more accurate way to determine the exact number
of potential factors that need to be tested at any given depth,
but requires a little more effort.  And when we're talking a
difference of a couple million potential factors with a total
of 100 trillion potential factors to test, is it really
important to know the exact number??


Eric Hahn

_
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Re: Mersenne: glitches in mprime v19?

[Eric Hahn]

Jason wrote:
>b)  When I killed mprime (v19), I realized that it had been
>*factoring* my highest exponent (which was not the
>current one being tested), when it's explicitly set up
>to do Lucas-Lehmer tests only.  Is this the intended
>behavior?  The number that it was factoring is > 710,
>if that's pertinent.

Was this exponent newly assigned or already had it been 
assigned at some point in the past?  All versions attempt
to trial-factor exponents (if necessary) to a certain
point before beginning the L-L tests.  To give an accurate
amount of work queued up, they will perform any necessary
trial-factoring (for those exponents to be L-L tested)
before they begin (or continue) any further L-L testing. 

As it happens, v19 has new breakpoints in trail-factoring.
For example, all exponents in the 8-9 million range had
previously been trial-factored only to 2^63, however v19's
breakpoints will cause additional trial-factoring to 2^64
to be attempted for exponents above 8.25 million.  There
are also some exponents (between 7-7.27 million) that
has only been trial-factored thru 2^62.  V19 will attempt
additional trial-factoring thru 2^63 for these exponents.

The limits for v18 and v19 trail-factoring (in millions) are:

Trial-FactoringV18V19
 thrurange(s)   range(s)
===   = ===
 2^72  ---  71.00  - 79.30
 2^71  ---  57.02  - 71.00
 2^70  ---  44.15  - 57.02
 2^69  ---  35.10  - 44.15 
 2^68  ---  28.13  - 35.10
 2^67  ---  21.59  - 28.13
 2^66  ---  17.85  - 21.59
 2^65  ---  13.38  - 17.85
 2^64 9.15  - 20.40  8.25  - 13.38
 2^63 7.27  -  9.15  6.515 -  8.25
 2^62 5.16  -  7.27  5.16  -  6.515
 2^61 3.96  -  5.16  3.96  -  5.16
 2^60 2.95  -  3.96  2.95  -  3.96
 2^59 2.655 -  2.95  2.36  -  2.95
 2^58 2.135 -  2.655 1.93  -  2.36
 2^57 1.675 -  2.135 1.48  -  1.93


Eric Hahn


_
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Re: Mersenne: Factors Everywhere

[Eric Hahn]

Will Edgington wrote:

>Eric Hahn writes:
>
> I've come up with this SWAHBI (like a SWAG, but an idea
>   instead of a guess).
>
>Hm, "silly, wild *ssed, half-baked idea" ?  That's not an acronym >I've
seen before.:)

Since I've been asked privately on numerous occasions,
I'll post here for everybody...  SWAHBI is an acronym for
"silly, wild-*ss, hare-brained idea!", but Will's
interpretation will do just fine too. :)  Actually, as I've
told a couple of people, I shouldn't insult rabbits like
that, even though the ideas tend to breed like them. 

Eric Hahn
...Who has found the 51-bit factor 1,152,058,136,977,799
of M(79,299,931)...and still searching on M(79,299,959).


_
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Re: Mersenne: Iteration Times (was: GIMPS client output)

[Eric Hahn]

At 09:47 AM 9/21/1999 -0700, James Escamilla wrote:
>Wouldn't the run time at 4.231 be about 10 years?

Yes, for that particular exponent (79,299,959), it would
take approx. 10 yrs. and 231 days to test.

That's assuming 4 items:
  1) A P2 266MHz PC was being used the entire time.
  2) The PC was being used exclusively to test the exponent 24/7.
  3) The 4.231 sec/iter is constant (which it isn't!)
  4) A factor isn't found (below 2^62 is unsuccessful at least!)

Eric Hahn
_
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Mersenne: Factoring

[Eric Hahn]

  Does anybody know if there is an exponent where the
factor is, or know whether there is a proof on whether
a factor can (or can't) be, a root??  A square??

To clarify this: 
We know that any factor of 2^p-1 is in the form 2kp+1.
Letting x >=2, 
  Can (2kp+1)^x = 2^p-1 ??
  Can (2kp+1)^x * (2kp+1) ... = 2^p-1 ??

Eric Hahn


_
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Mersenne: Iteration Times (was: GIMPS client output)

[Eric Hahn]

Okay, okay... obviously a lot of people were awake 
(you can stop flooding me with emails!!)

In a previous message I wrote:

>P.S. At the 79.3M range, you'll probably not want to set it
>at 100 iterations...  Per iteration time on 266MHz PII with
>64MB RAM is 58.781 seconds!!!  (Yes, it's true, but I'm also
>just checking to see if anybody's awake :))

I went back to the exponent in question and ran another test.

There are a couple of notes here:
  1) This originally was done for a particular test in QA.
  2) George didn't have the new timings up at the time.
  3) I thought it was high myself, but what did I know?

What I found was:
  1) I obviously had something running in the background
 I was not aware of.
  2) The actual time dropped to 4.231 sec/iter
  3) Amazingly, there didn't appear to be much HDD paging
 happening except went you hit 'STOP'!

BTW, for those of you who don't know (or actually asked),
these exponents use 4096K FFT runlengths, and 16M save
files...

Eric Hahn


_
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Mersenne: Interesting PrimeNet Error

[Eric Hahn]

Ah, here's something interesting...

I was working on a machine which was running Prime95 (v18,
BTW, and in a visible window), when it decided to contact
PrimeNet.  No Problem!  It sent the text messages about
trial-factoring until:

[...]
Sending text message to server:
M10461667 has a factor: 7841028322998353783
Sending expected completion date for M10461667: Sep 21 1998
ERROR 11: Exponent already tested.
[...]

Yes, the expected completion date message was expected as
the machine was still testing (for smaller factors),
and was sitting at 127520*2^32 (Pass 5 of 16) at the
time it did this...

I just found it interesting that PrimeNet would produce an
error like this.  What would happen if Prime95 should happen
to find a smaller factor?  Would it be accepted?  H.....

Eric Hahn
_
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

RE: Mersenne: GIMPS client output

[Eric Hahn]

Rick,

  Glad to see *somebody's* awake!! 

>From: Eric Hahn
>
>> P.S. At the 79.3M range, you'll probably not want to set it
>> at 100 iterations...  Per iteration time on 266MHz PII with
>> 64MB RAM is 58.781 seconds!!!
>
>The only question that comes to mind is if you had to plough
>through factoring before you got to the LL test...but then I
>realise that you still wouldn't be done if that were true.

You're right!  Even on a P3-500, it'd take 7-8 months to plough
through all the factors to 2^72.  I intentionally told it that
it had been factored thru 2^73 to prevent it from doing such.
This was for a test I was running...

>I signed up for an exponent in the 33mil range and the factoring >alone
took 13 days on a P3-500. I'd originally does it for testing >purposes, but
after that I've just got to let it continue. :-)

I've got 2 machines working on 10M digit exponents.  One will
work until completion, while the other will be forced to
trial-factor only (a feature not offered in v19 which I've
mentioned to George).

>In a year's time, I'd love to see some numbers on how many signed
>up for tem million digit numbers and later quit for smaller 
>exponents...

Well, let's see...  You got yours assigned Sept. 5 at 3:38 UTC.
14 exponents assigned, 3 factored, 11 still in progress...
and counting...

Interesting to note, however, that 2 of the exponents factored
and 1 still in progess had factors listed on Alex Kruppa's
site: http://www.informatik.tu-muenchen.de/~kruppa/M33M/index.html
before 10M digit exponents were assigned by IPS.

Which ones??  33,219,341 and 33,219,469 and 33,219,707
(33,219,341 was assigned by IPS to Alex, BTW )

Eric Hahn


_
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Re: Mersenne: GIMPS client output

[Eric Hahn]

>Iteration: 164000 / 8410531 [1%].  Clocks: 115665753 = 0.496 sec.
>
>Might be nice to display the percentage out to an accuracy that changes
>every hundred iterations.  Hmm, looks like that's an integer of the
>percentage, not rounded.  Guess it doesn't matter.  For the one I'm
>working on it looks like 3 decimal places would be needed to see a >change
every 100 iterations.

v19 allows this by manually adding 'PercentPrecision=' to the
PRIME.INI file (Prime95 must be stopped and exited before
editing, and then restarted).  The valid range after the '='
is 0 to 6, therefore you can have it say:

Iteration: 164000/8410531 [1.949936%]. Per iteration time: 0.496...
Iteration: 164100/8410531 [1.951125%]. Per iteration time: 0.496...

Mind you, even at the limit of v19 (79.3M), setting it to a
value of 4, and having screen outputs at every 100 iterations,
will still cause the value to increase (although by 0.0001%)

Eric Hahn

P.S. At the 79.3M range, you'll probably not want to set it
at 100 iterations...  Per iteration time on 266MHz PII with
64MB RAM is 58.781 seconds!!!  (Yes, it's true, but I'm also
just checking to see if anybody's awake :))


_
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Re: Mersenne: Factors Everywhere

[Eric Hahn]

>>   What I'm looking for is the following two items for *all*
>> Mersenne numbers 2^p-1 where p is prime and p>1:
>
>  It can be proven that there are an infinite number of these.

Yeah, right, I knew that...  I guess I should've clarified
and said for all of them that the information is known :(  
If no information is known where p>100M, then what can I do??

>>   1) All known factors (including, but not limited to,
>>  the smallest known factor (noted if it isn't))
>>   2) Largest potential factor attempted
>>   I ask that the two items are human-readable at the
>> very least.
>
>  Will Edgington maintains this information, but it may be
>hundreds of megabytes in size.  If a website, such as
>Entropia, has the space it will be useful to make this database
>available (in many small compressed files) so that others may
>use it.

Isn't the majority of the information he has in
machine-readable format though??  I can't make much use
of it, if I can't read it...

Eric Hahn

_
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Mersenne: Factors Everywhere

[Eric Hahn]

Ok,

  I've come up with this SWAHBI (like a SWAG, but an idea
instead of a guess).

  What I'm looking for is the following two items for *all*
Mersenne numbers 2^p-1 where p is prime and p>1:
  1) All known factors (including, but not limited to,
 the smallest known factor (noted if it isn't))
  2) Largest potential factor attempted
  I ask that the two items are human-readable at the
very least.

  I've pulled a couple of files off mersenne.org 
(FACTORS.ZIP and NOFACTOR.ZIP) as well as off 
Alex Kruppa's page.  While the files appear complete
as far as I can tell, they only cover the ranges
of p between 11 - 9,999,991 and 33,219,281 - 35,999,993.
They also don't cover *all* known factors!
  Any and all information on the ranges between
10M - 33.22M and >36M is greatly appreciated, as well
as any known factors not listed in the files I've
pulled.

Eric Hahn


_
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

RE: Mersenne: Suggestions for Prime95 v19

[Eric Hahn]

::Reto Keiser <[EMAIL PROTECTED]> wrote:
>Now before the new version of Prime95 is released I have
>some suggestions for new function which should not be too
>difficult to add:

Some of these functions exist already in v18 and prior
versions, just not as you might think...

>- A menu item that forces the program to write
>  intermediate data to disk. It is useful, when the user
>  wants to install a new program or play a game which
>  probably forces the computer to crash. So it is
>  possible to save data without exiting the program
>  before a riskful action.

Prime95 already does this if you use the menu items
TEST | STOP and then TEST | CONTINUE.

>- A function which prvents writing to disk for some
>  time. When the user writes a CDr, it sometimes is
>  dangerous, when prime95 writes intermediate results
>  to disk during that time.

Again, you can either use the procedure above to stop
Prime95 before and start it after CD-R recording, or you
can change the minutes between disk writes under
OPTIONS | PREFERENCES before beginning recording.

>- Extended status information
>  -relative speed of the system (e.g. using rolling average)
>  -hours in use

Not sure what you're looking for here...  Possibly, the same
information Prime95 uses to calculate ECD (estimated
completion dates)??

>  -# flops done (calculated)

Hmmm... This seems like it might be a little difficult.
First, Prime95 uses integer code on 486, Cyrix, and
AMD K5 chips when performing factoring.  Second, each
iteration of a test involves many calculations.  Third,
Prime95 is running as a background (idle process) task.

>  -# iterations done  (total of all exponents)
>  -history: all tested iterations on this machine 

Take a look at the RESULTS.TXT file in the directory
with Prime95.  It lists the results from all
previous exponents...  

>  -processor usage (compared with the unused system

Running as a background (idle process) task makes this
unfeasible.  You'd be better off using something
like WinTop in Windows95 (found in the Win95 KernelToys)
or something like it for other OSes...

Eric Hahn


_
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

RE: Mersenne: Multiple residues - enhancing double-checking

[Eric Hahn]

Based on previous messages in this thread, I'm going
to throw in my 2 cents...  (and avoid a lot of
quoting!)

While the reporting of partial residues at specific
points, say every 10% (or 5% over 20M), isn't a bad
idea, it won't necessarily save a whole lot of time.

The only thing this scheme would accomplish is to
allow a third test to begin (if a mismatch is found
somewhere along the way) before the second one
finishes.  If the third test did match the first,
there would be savings in discarding the second.
What if, however, the third test matched the second?
Both tests would have to complete, and some safeguard
would have to be a place should the third test complete
before the second.  

This will increase the logistics a lot (but not make
it impossible).  The client would be required to report
most of the information to the server, without receiving
much from the server (a stop, go, or discard maybe).
A checksum figure as part of the work file, as somebody
suggested (shown below), wouldn't work well if the latter
case above occurred (2nd and 3rd test match).

>Double-Check=
>M23780981,64,863FF87,678676AA,FF637BC,[...],CRC:9923FDA.

Much more than the logistics, however, would be the
confusion facter.  This would likely increase
exponentially, especially when attempting to determine
the current overall status of the project.  We might
even have to have George committed eventually, when
he starts running his fingers up and down across his
lips or rubs the side of his head to the bone with his
fingers or palm of his hand... :-(

I think as the time increases for each LL test, there
would be much more time savings in attempting to do
higher trial-factoring.

Let's look at some figures using the following:
 1) We assume to be using a PII 233MHz.
 2) an LL test takes a year (around 19.3M)
(AND HEY! This is 4 to 5 years away!!)
 3) current trial-factoring to 2^64 takes 2 days if
no factor is found.
 4) currently, only about 13% of exponents are actually
factored, with the rest requiring an LL test.
 5) 2 LL tests are done for each exponent (an
original and a double-check) 

Current trial-factoring saves 12.5% of the total time
that would be spent without any trial-factoring.

If we were to trail-factor to say, 2^70 (which should
cause factor time to increase to 1 month), without any
additional improvement to exponents being factored this
will cause a drop to about 8.8% overall time saved.

However, for each % improvement in exponents being
factored, overall time saved would increase by a little
over 1%.  As a result, if we were to improve to 20% of
the exponents being factored, we would save close to 16%
of the overall time spent without any factoring.

Of course, even more time would be saved by factoring,
if an exponent that would have been factored had it been
trial-factored to 2^70, was to be determined to need a
triple-check during LL testing because it wasn't factored
during a trail-factor process to 2^64

In conclusion, even with a new algorithm that halves
the time for an LL test, 1 month to factor an exponent
still beats a year to perform an LL test and its
corresponding double-check. In addition, it should be
easier to speed up the factoring process than the LL
testing process.


_
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Re: Mersenne: The $100,000 award for 10,000,000 digit prime

[Eric Hahn]

George Woltman wrote:
>Hi all,
>
>   At the risk of opening Pandora's box, I'd like to bring
>up the possibility of splitting up the $100,000 award for a 10 million
>digit prime.  I'm soliciting everyone's opinion before making a decision.
>

1/4 to George or charity (his choice)
1/4 to Scott or charity (his choice)
1/2 to the discover(s) or charity*

*The discover(s) get to chose only if there is orderly
exploration of exponents. Otherwise, it goes to a 
charity of their choice.

That would be changed to 20%, 20%, 40%, and 20%, with the
last 20% going to the individual(s) responsible for
increasing the search speed significantly, if such event
occurs.

This promotes an orderly exploration of exponents, yet
allows those who want to find a 10M digit prime just
for fun (and unorderly) to have the opportunity without
being completely penalized.  It also encourages the
advancement and development of new algorithms.

This is all, of course, assuming a GIMPser is the
discover(s)...


_
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ  -- http://www.tasam.com/~lrwiman/FAQ-mers

Re: Mersenne: M38 = M6972593

[Eric Hahn]

>NOW it does, after the official announcement   Remember
>when Roland found M37?   Someone found a 0x000 
>residue in the report and beat George to the punch, so Scott
>modified the reports so that they would NOT post a zero 
>residue automatically.   So THIS time, when word came that
>we'd found a potential prime, some enterprising person
>immediately grabbed the "assigned exponents" file, and the
>"cleared exponents" file, and by the process of elimination,
>deduced the prime number because it was the ONLY candidate
>listed as "assigned" but was not EITHER cleared as non-prime
>or still in progress.

Actually, it was updated and added on July 5.  Previously,
the cleared exponent list looked like the following
(accounts removed for space):

6972451 62 0x1921D245846367__25-Jun-99 15:07  
6972467 62 0x01123F0756E444__03-Jul-99 11:27  
6972509 62 0x681B51793464A4__17-May-99 06:07  
6972617 62 0xC377193C8903C1__05-Apr-99 05:25  
6972649 62 0x30982ED7214ACA__09-May-99 12:49  
6972709 62 0xEADF232189A0F0__21-Jun-99 08:30  

>George was telling Scott to correct for this 'leak' so that
>a really determined person could not do a comparison-elimination
>to deduce a prime number find before George announces it.

Fixing this one 'leak' won't do the job, if you know how
and where to look...

Besides, *some people* know how to keep quiet about certain
things.  You didn't see this person going around announcing
it to the world immediately after it was found, did you???
In fact, their website didn't post it being found until after
it was verified, and even then, didn't disclose the number!!

On the other hand, they could've noticed a discrepany and
shrugged it off as meaningless until after word got out a
new prime was found.  At that point, they could've gone
back and said to themselves '*that explains the discrepany!*'.

Just a couple of possibilities

>Of course, Curt Noll's web page made that a pointless exercise... ;-)

>> >(Note to Scott - create a dummy non-zero residue a stick it
>> >in the cleared exponents report).
>>
>>Too late!!  The Cleared Exponents Report reads:
>>
>>6972593  62  P 0x  01-Jun-99 13:57  nayan  precision-mm



Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm

Mersenne: SJ Mercury News

[Eric Hahn]

For those of you who are interested, the San Jose
Mercury News has published the story.

http://www.mercurycenter.com/premium/scitech/docs/prime06.htm



Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm

Mersenne: M38 = M6972593

[Eric Hahn]

>(Note to Scott - create a dummy non-zero residue a stick it
>in the cleared exponents report).

Too late!!  The Cleared Exponents Report reads:

6972593  62  P 0x  01-Jun-99 13:57  nayan  precision-mm



Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm

Mersenne: IPS Factoring Assignments

[Eric Hahn]

I was just about going to ask if George was going to
more factoring assignments available to IPS or if 
IPS just wasn't showing ones that had been made
availabe, when I noticed that the range of 
10.0 - 10.2 Mil was posted.

Now instead of having enough for about 2 weeks,
there are enough for about 7 weeks, since GIMPS
members go through them at a rate of ~1000 per week



Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm

Mersenne: Mersenne M38

[Eric Hahn]

>On Mon, Jun 28, 1999 at 07:45:11PM -0700, Eric Hahn wrote:
>>It hasn't been announced yet... but from what little information 
>>that is available, i.e. The Oregonian newspaper article, the
>>exponent must be =at least= 6,643,859.

>Hmmm, my guess was at about 6,2 million, but nobody else guessed,
>so there :-)

Actually, now that the exponent for M38 is known, I can say
that I had narrowed it down to 5 candidates (7 before the 
Oregonian article).  They were:
5,750,881 6,382,513 6,836,327 6,972,593
7,143,163 7,213,391 7,310,981

These were the only exponents that were no longer being
worked on in one form or another, and was not listed on the
cleared exponents list, for that time frame...

I determined this from the statistics I've been tracking
for a while now.  Part of which I've now posted to my website
at ( http://www.mcn.org/2/ehahn/netforce/ips-stats.html ).
I'll be posting more as I get them reformatted to look better...

Eric


Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm

Mersenne: Prime95 and speed

[Eric Hahn]

>Has anyone else noticed Prime95 executing at twice the speed
>while factoring then slowing down when it gets to a certain
>point in the factoring process? 
>Let me clarify a bit more...I have a PII500 that while
>working on a factor for M9899041 does about .050 seconds
>per iteration.  I've noticed that it does about .029
>seconds per iteration when it is factoring through
>1069176222*2.  Is there some reason why there would be 
>such a huge difference in speed after that point?

Actually, the point is closer to 107350*2^32, and yes
the change is normal.  It happens after the program gets
through the trial factors up to 2^62. After it reaches the
upper limit of 2^64 (approx. 429000*2^32), it goes back
down.  It's partially a result of the fact that there are
many more trial factors to test between 2^62 and 2^64.

>I've done the usual things - make sure nothing else
>is running, run WinTop, etc.  Prime95 is getting 
>nearly 100% of the CPU power all the time.

Again, it's normal.  You'll probably notice the iteration
time at a ratio of 9/5 for the higher range (2^62 - 2^64)
of trial factors...


Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm

Mersenne: Re: Mersenne Digest V1 #590

[Eric Hahn]

>>>Has the prime number that was found a week ago been announced on 
>>>this list? 
>>>I.E.  What number was it? 

>>It hasn't been announced yet... but from what little information 
>>that is available, i.e. The Oregonian newspaper article, the 
>>exponent must be =at least= 6,643,859. 

>>Eric 


>Eric: Isn't 7 million bits something very near to 2^7,000,00  ? 

>I think that could be the case. So could we say: exponent at least >6,900,000? 

>Rudy 

>From the "The Oregonian" article: 

>The new number is 7 million bits of information -- or more than 
>twice as long. 


Good point.  But 7,000,000 bits =is= 2^7,000,000 - 1 (which is
obviously a composite number)

I was looking at the following portion of the article...

'Confirmed this week by George Woltman, a Florida engineer and 
founder of the "Great Internet Mersenne Prime Search," the new 
prime possesses more than 2 million digits -- more than twice as
many as the previously largest-known prime, which was discovered
last year by a 19-year-old college student.'


Whatever the case, certain individuals who have decided to "poach"
exponents to ensure M(36) and M(37) are actually M(36) and M(37)
respectively, are going to have to wait a lng time to verify
whether this new find is actually M(38) or really M(39), etc.
instead.  Guess they better get out those Pentium XV 1000GHz 
processors we heard about earlier.  They'll need them to process
the well over 35,000 LL tests (including double-checks) to
accomplish this task!!!  



 Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm 

RE: Mersenne: A few questions

[Eric Hahn]

>How large will the exponent be for a 10,000,000 digit prime number?

To be a 10,000,000 digit prime number the exponent must be at least
33,219,281 (which also happens to be a Mersenne candidate).

>Has the prime number that was found a week ago been announced on this
>list?
>I.E.  What number was it?

It hasn't been announced yet... but from what little information 
that is available, i.e. The Oregonian newspaper article, the
exponent must be =at least= 6,643,859.

Eric


Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm

RE: Mersenne: A few questions

[Eric Hahn]

CORRECTION TO LAST MESSAGE!

The exponent 33,219,281 happens to be a Mersenne prime candidate!



Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm