Mersenne Digest         Tuesday, June 6 2000         Volume 01 : Number 743




----------------------------------------------------------------------

Date: Sat, 03 Jun 2000 16:48:49 -0400
From: George Woltman <[EMAIL PROTECTED]>
Subject: Mersenne: Factor does not divide N!

Hi,

        A few people reported "ERROR: Factor does not divide N!" errors
during P-1 or ECM factoring.  The bug has been located and fixed in
version 20.5.

        The bug occurs when the memory settings change in the
middle of a GCD.  This includes the change that can occur at day/night
transitions.

        Obviously, you are not required to upgrade as this error is pretty
rare....

Regards,
George

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

------------------------------

Date: Sun, 4 Jun 2000 06:23:55 -0400
From: "Vincent J. Mooney Jr." <[EMAIL PROTECTED]>
Subject: Mersenne: Yikes !!  Restart?

I was testing 9,028,373 from a worktodo.ini file that said

Test=9028373,63

That is all the worktodo.ini file said.  I use manual prime retrieval and
asked for, and got from George, three new numbers as 9,028,373 was my only
number.

The worktodo.ini file was changed to 

Test=9028373,63
Test=new number 1,60
Test=new number 2,60    
Test=new number 3,60

There are line feeds at the end of the ,63 and ,60 so there are no extra
blanks anywhere in the worktodo.ini file.  The changes were made while
9,028,373 was running with notepad or one of the other simple MicroSoft
utilities.  The changes were tehn saved and the worktodo.ini file has the
four numbers.

Suddenly, 9028373, which was at 14% done, disappeared!!  In its place,.the
P-III (450 MHz) was factoring new number 1 (pass 1 of 16).  There is
nothing, nada, zilch, zippo, about the loss of 9028373 in the results file.

Why?  It is true that I briefly shut down as I often do to clear Java files,
but I invariably go to the LL test screen, click for STOP and then click for
EXIT.  At startup, the LL testing starts up again automatically (thanks to
some one who gave me fine explicit instructions as to how to do this).  I
believe the STOP and then EXIT saves the latest p and q files so I lose only
a few minutes, not up to 1/2 hour or whenever the last p and q files were
saved.  

I have often used Norton Utilities to (a) system check for errors and there
is a persistant error that crops up from playing Java based chess (after 15
or so games; it takes that many to win just once) and to (b) speed disk,
(another Norton Utilities feature),  i.e., reorganize the C drive.  But I
have been doing this for MONTHS AND MONTHS while running LL tests (more than
250 done over the years) and have never had an ill effect.

I will have to restart 9028373 but then, why did it stop?  Is this a
microsoft feature (i.e. a bug that in an undocumented yet powerful add on)?

Also, should I just stop the factoring passes and restart so that I am back
again on prime 9028373?

The MERSENNE directory where I have all the files and programs has a
p9028373 file, a q9028373 file and a p file for the new number.  I'd like to
resume on the p and q files for 9028373, obviously.

Anybody can respond.  Ask for more info if you need it.


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

------------------------------

Date: Sun, 4 Jun 2000 15:02:52 +0200
From: "Steinar H. Gunderson" <[EMAIL PROTECTED]>
Subject: Mersenne: Re: Yikes !!  Restart?

On Sun, Jun 04, 2000 at 06:23:55AM -0400, Vincent J. Mooney Jr. wrote:
>Suddenly, 9028373, which was at 14% done, disappeared!!  In its place,.the
>P-III (450 MHz) was factoring new number 1 (pass 1 of 16). 

This is quite normal. From readme.txt:

- ---
Furthermore, the program may start factoring
exponents before a previous Lucas-Lehmer test completes.  This is normal!
The program will resume the Lucas-Lehmer test when the factoring
completes.
- ---

Don't worry -- your LL test will start again when the factoring completes.

/* Steinar */
- -- 
Homepage: http://members.xoom.com/sneeze/
_________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ      -- http://www.tasam.com/~lrwiman/FAQ-mers

------------------------------

Date: Mon, 5 Jun 2000 00:05:39 -0400
From: "Vincent J. Mooney Jr." <[EMAIL PROTECTED]>
Subject: Mersenne: Replies to Yikes !!  Restart?

The consensus, as I read the messages, is that all is O.K.
Soon I will have
Test=9028373,63
Test=999....,63
Test=999....,63
Test=999....,63

and LL factoring will resume on 9028373.  I hope this is right as I will be
away for a week starting Tuesday, June 6, 2000.

All in all, there is and has not been any lost time as the factoring was
going to be done anyway.

I am running Version 19.  The improvements to version 20 seem slight.

At 06:23 AM 6/4/00 -0400, you wrote:
>I was testing 9,028,373 from a worktodo.ini file that said
>
>Test=9028373,63
>
>That is all the worktodo.ini file said.  I use manual prime retrieval and
>asked for, and got from George, three new numbers as 9,028,373 was my only
>number.
>
>The worktodo.ini file was changed to 
>
>Test=9028373,63
>Test=new number 1,60
>Test=new number 2,60    
>Test=new number 3,60
>
>There are line feeds at the end of the ,63 and ,60 so there are no extra
>blanks anywhere in the worktodo.ini file.  The changes were made while
>9,028,373 was running with notepad or one of the other simple MicroSoft
>utilities.  The changes were tehn saved and the worktodo.ini file has the
>four numbers.
>
>Suddenly, 9028373, which was at 14% done, disappeared!!  In its place,.the
>P-III (450 MHz) was factoring new number 1 (pass 1 of 16).  There is
>nothing, nada, zilch, zippo, about the loss of 9028373 in the results file.
>
>Why?  It is true that I briefly shut down as I often do to clear Java files,
>but I invariably go to the LL test screen, click for STOP and then click for
>EXIT.  At startup, the LL testing starts up again automatically (thanks to
>some one who gave me fine explicit instructions as to how to do this).  I
>believe the STOP and then EXIT saves the latest p and q files so I lose only
>a few minutes, not up to 1/2 hour or whenever the last p and q files were
>saved.  
>
>I have often used Norton Utilities to (a) system check for errors and there
>is a persistant error that crops up from playing Java based chess (after 15
>or so games; it takes that many to win just once) and to (b) speed disk,
>(another Norton Utilities feature),  i.e., reorganize the C drive.  But I
>have been doing this for MONTHS AND MONTHS while running LL tests (more than
>250 done over the years) and have never had an ill effect.
>
>I will have to restart 9028373 but then, why did it stop?  Is this a
>microsoft feature (i.e. a bug that in an undocumented yet powerful add on)?
>
>Also, should I just stop the factoring passes and restart so that I am back
>again on prime 9028373?
>
>The MERSENNE directory where I have all the files and programs has a
>p9028373 file, a q9028373 file and a p file for the new number.  I'd like to
>resume on the p and q files for 9028373, obviously.
>
>Anybody can respond.  Ask for more info if you need it.
>

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

------------------------------

Date: Mon, 05 Jun 2000 13:09:42 -0700
From: Eric Hahn <[EMAIL PROTECTED]>
Subject: Mersenne: M#39, M#40, M727, M751, et al.

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

------------------------------

Date: Tue, 06 Jun 2000 10:52:31 -0700
From: Eric Hahn <[EMAIL PROTECTED]>
Subject: Mersenne: Clarification on M#39, M#40, M727...

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

------------------------------

End of Mersenne Digest V1 #743
******************************

Reply via email to