Mersenne Digest Tuesday, October 2 2001 Volume 01 : Number 888 ---------------------------------------------------------------------- Date: Sun, 30 Sep 2001 16:07:34 -0700 From: "Daniel Swanson" Subject: Mersenne: Re: Factoring Failure? A follow-on to my previous message: I went through the Cleared Exponents report looking for other examples of factors found during double-checks that should have been found during the initial factorization. I found the following 7 examples, including the one I just reported: 5977297 53 DF 6726544627832489 26-Aug-01 12:03 TempleU-DI C031EBA9B 6019603 57 DF 137024179940485697 18-Aug-01 18:55 TempleU-DI C031EBA9B 7019297 57 DF 160100125459121849 27-Sep-01 22:52 TempleU-DI TD01489_Cub1 7020641 58 DF 226230108157229263 30-Sep-01 02:05 RayPelzer Homebase 7025987 56 DF 74052063365823791 30-Sep-01 01:12 shaneamy P600A 7027303 55 DF 31090234297428433 30-Sep-01 20:58 dswanson nosnawsd 10159613 56 DF 68279769831982367 19-May-01 10:13 hornup lbe_pc Seems to be a big clump in the 701xxxx - 702xxxx range. Given that this is at the leading edge of numbers currently being assigned for double-checks, I'd be willing to bet several more will turn up in the next few days. Were numbers in this range all originally factored by the same user or computer? Another interesting note: Given the number of different computers working double-checks, what are the odds that TempleU-DI/C031EBA9B would pick up TWO of these?!? Dan _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Mon, 01 Oct 2001 12:35:59 EDT From: EWMAYER@aol.com Subject: Re: Mersenne: Odd warning in mlucas .stat file ? Alex Phillips wrote > I recently updated my E450 running Mlucas to version 2.7b, using Bill > Rea's precompiled version from Ernst's website. I'm attempting to use the > mlcuas.cfg file which comes in this tarball, but I get the following error > in my pxxxxxxxx.stat file :- > > Restarting M(12xxxxxx ) at iteration 6484000 > WARN: radix set -1 not available - using defaults. > Using complex FFT radices 10 32 32 32 > M( 12xxxxxx ) iteration = 6486000 clocks = 00:14:16.236. > Res64:36B6CB8618DD551D > WARN: radix set -1 not available - using defaults. > Using complex FFT radices 10 32 32 32 > > Can anyone explain what this means ? For some reason the program is not finding, or is unable to properly read the mlucas.cfg file. The obvious first check (you've probably done this, but just in case) is to make sure there's a copy of the .cfg file in the local directory from which you're running the job. If as i do) you're running on a multiprocessor machine and have one master copy of the executable, plus soft links to it in each of the various subdirectories from which you're running jobs, there needs to be a copy of the .cfg file in each subdirectory, obviously. Also make sure you have read permission for the file. Assuming you've done the above, look at the .cfg file, preferably using an editor which shows the ^M linefeed characters that some ftp utilities introduce into text files. If there are any such, strip them out. (I don't actually know if they'll cause a read problem, but it's best to be safe.) Note that you can modify the .cfg file while the program is running - at worst the program won't be able to read it and will use the defaults, i.e. you'll be no worse off than at present. Finally, make sure the .cfg file has the proper format, namely # comment line 1 # comment line 2 # comment line 3 200000 # comment line 4 {FFT length 1, in K} {FFT radix set index 1} {FFT length 2, in K} {FFT radix set index 2} .. If all that checks out and the program still can't read the file, do cat *cfg rm -f *cfg cat>>mlucas.cfg then paste the output of the first 'cat' into stdin and type ctrl-d to finish input. I've had some rare cases where my run similarly was unable to read the .cfg file, and in the end the only thing that worked was to delete and recreate the file - OS weirdness most likely, but at the moment I don't remember which OS this happened under. Good luck, - -Ernst p.s.: FYI, Mlucas 2.7c (faster, of course!) will be coming out by the end of the month (hopefully sooner, but not later.) I'll update the timing pages by then, as well. _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Mon, 01 Oct 2001 15:01:05 -0400 From: George Woltman Subject: Re: Mersenne: Re: Factoring Failure? Hi, At 04:07 PM 9/30/2001 -0700, Daniel Swanson wrote: >I went through the Cleared Exponents >report looking for other examples of factors found during double-checks that >should have been found during the initial factorization. > 5977297 53 DF 6726544627832489 > 6019603 57 DF 137024179940485697 > 7019297 57 DF 160100125459121849 > 7020641 58 DF 226230108157229263 > 7025987 56 DF 74052063365823791 > 7027303 55 DF 31090234297428433 >10159613 56 DF 68279769831982367 >Were numbers in this range all originally factored by the same user or >computer? My logfiles from that long ago have been zipped and stored on CDROM. It is possible that 7,010,000 - 7,030,000 were all factored by one person. It was not uncommon for me to hand out large blocks for factoring to users without Internet connections. While I no longer do this, there are a handful of users pre-factoring the 20,000,000 - 80,000,000 area. I hope their machines are reliable!! They probably are as they are finding the expected number of factors. Anyway, it doesn't appear to be a program bug as you were able to find the factor with trial factoring. I'm guessing either bad hardware or an older prime95 version had a bug. 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. Thanks for the interesting findings! Regards, George _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Mon, 1 Oct 2001 22:23:38 +0200 From: "Jean-Yves Canart" Subject: FW: Mersenne: Re: Factoring Failure? Hello all, I have browsed some logs I archived long time ago and I have found this: In may 1998, one user, "tomfakes", cleared around 80 exponents with factor found = "1" It was in the range 7013000-7055000. Regards, Jean-Yves > -----Original Message----- > From: mersenne-invalid-reply-address@base.com > [mailto:mersenne-invalid-reply-address@base.com]On Behalf Of George > Woltman > Sent: lundi 1 octobre 2001 21:01 > To: Daniel Swanson; Mersenne Digest > Subject: Re: Mersenne: Re: Factoring Failure? > > > Hi, > > At 04:07 PM 9/30/2001 -0700, Daniel Swanson wrote: > >I went through the Cleared Exponents > >report looking for other examples of factors found during > double-checks that > >should have been found during the initial factorization. > > 5977297 53 DF 6726544627832489 > > 6019603 57 DF 137024179940485697 > > 7019297 57 DF 160100125459121849 > > 7020641 58 DF 226230108157229263 > > 7025987 56 DF 74052063365823791 > > 7027303 55 DF 31090234297428433 > >10159613 56 DF 68279769831982367 > >Were numbers in this range all originally factored by the same user or > >computer? > > My logfiles from that long ago have been zipped and stored on CDROM. > It is possible that 7,010,000 - 7,030,000 were all factored by one person. > It was not uncommon for me to hand out large blocks for factoring to > users without Internet connections. While I no longer do this, there are > a handful of users pre-factoring the 20,000,000 - 80,000,000 area. I hope > their machines are reliable!! They probably are as they are finding the > expected number of factors. > > Anyway, it doesn't appear to be a program bug as you were able to find > the factor with trial factoring. I'm guessing either bad > hardware or an older > prime95 version had a bug. 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. > > Thanks for the interesting findings! > > Regards, > George > > _________________________________________________________________________ > Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm > Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Mon, 01 Oct 2001 21:44:32 +0100 From: Alex Phillips Subject: Re: Mersenne: Odd warning in mlucas .stat file ? At 12:35 01/10/01 -0400, Ernst wrote: >---SNIP--- >Assuming you've done the above, look at the .cfg file, >preferably using an editor which shows the ^M linefeed >characters that some ftp utilities introduce into text >files. If there are any such, strip them out. (I don't >actually know if they'll cause a read problem, but it's >best to be safe.) - ----SNIP---- That was it, I had used winzip to open the .gz file to a Samba network drive on the sun box, and somehow had inserted ^M on each line. >Good luck, >-Ernst > >p.s.: >FYI, Mlucas 2.7c (faster, of course!) will be coming out >by the end of the month (hopefully sooner, but not >later.) I'll update the timing pages by then, as well. Good News, I look forward to it. Many Thanks, Alex. _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Tue, 2 Oct 2001 19:52:42 -0000 From: bjb@bbhvig.uklinux.net Subject: Re: FW: Mersenne: Re: Factoring Failure? On 1 Oct 2001, at 22:23, Jean-Yves Canart wrote: > I have browsed some logs I archived long time ago and I have found > this: > > In may 1998, one user, "tomfakes", cleared around 80 exponents with > factor found = "1" It was in the range 7013000-7055000. Well, (s)he's not lying - 0 = n (mod 1) is a property of integers ;-) In any event: (a) this is the _opposite_ of the reported problem - what seems to have happened is that "no factor found" was being reported, sometimes erroneously; (b) this won't get through now PrimeNet validates submitted factors; the code I wrote for this purpose rejects as garbage any single-digit factor, after stripping off any leading zeroes as well as white space. (Obviously a Mersenne number with a prime exponent p > 5 cannot have any factors less than 10, and we know pretty much all there is to know about exponents up to and including 5, so excluding these is not a practical problem). > > At 04:07 PM 9/30/2001 -0700, Daniel Swanson wrote: > > >I went through the Cleared Exponents > > >report looking for other examples of factors found during > > double-checks that > > >should have been found during the initial factorization. > > > 5977297 53 DF 6726544627832489 > > > 6019603 57 DF 137024179940485697 > > > 7019297 57 DF 160100125459121849 > > > 7020641 58 DF 226230108157229263 > > > 7025987 56 DF 74052063365823791 > > > 7027303 55 DF 31090234297428433 > > >10159613 56 DF 68279769831982367 > > >Were numbers in this range all originally factored by the same user > > >or computer? > > > > My logfiles from that long ago have been zipped and stored on CDROM. > > It is possible that 7,010,000 - 7,030,000 were all factored by one > > person. It was not uncommon for me to hand out large blocks for > > factoring to users without Internet connections. While I no longer > > do this, there are a handful of users pre-factoring the 20,000,000 - > > 80,000,000 area. I hope their machines are reliable!! They > > probably are as they are finding the expected number of factors. The primes from that block of 20,000 numbers represents quite a bit of work and maps poorly onto the "missed" factors reported. A few mistakes are inevitable but, since testing a factor takes of the order of a microsecond on current systems, hardware glitches shouldn't be much of a risk. (? Unless they get into the code stream used to generate potential factors?) Reports of two "missed" factors of exponents within spitting distance of 6,000,000 and no less than four just over 7,000,000 looks high for random glitches to be responsible, even on really ropy hardware. Remember that P-1 (which found the factors missed by trial factoring) can only find a small proportion of the "small" factors, especially when it's being run with "double checking" limits. > > > > Anyway, it doesn't appear to be a program bug as you were able to > > find the factor with trial factoring. I'm guessing either bad > > hardware or an older prime95 version had a bug. If it _was_ Prime95. There are other factoring programs out there; maybe there was a higher incidence of use about 3.5 years ago when these exponents would have been the subject of factoring assignments. > > 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. However if it could be established that all the "missed" factors reported were the work of one user, perhaps it would be worth fixing the database to force rerunning of trial factoring for those factoring assignments run by that user when the exponents are reassigned for double checking (or LL testing). Regards Brian Beesley _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Tue, 2 Oct 2001 13:39:42 -0700 From: "Aaron Blosser" Subject: Re: FW: Mersenne: Re: Factoring Failure? If we could indeed track these to a single user, I've got about 25-30 AMD 1.2 GHz processors that I could throw at the situation for a short time, just to quickly re-trial factor these and put our minds to rest. Aaron - ----- Original Message ----- > However if it could be established that all the "missed" factors > reported were the work of one user, perhaps it would be worth fixing > the database to force rerunning of trial factoring for those factoring > assignments run by that user when the exponents are reassigned > for double checking (or LL testing). > > Regards > Brian Beesley _________________________________________________________________________ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers ------------------------------ Date: Tue, 2 Oct 2001 23:09:31 -0500 From: "Steve Harris" Subject: Re: FW: Mersenne: Re: Factoring Failure? - -----Original Message----- From: bjb@bbhvig.uklinux.net To: mersenne@base.com 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. Oh well, Steve _________________________________________________________________________ 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 #888 ******************************