Re: Mersenne: V17 bug discovery and preventive measures
I agree with everything in this e-mail. Especially the parts about George doing a great job. However I think for this type of development process to be useful, we need independent software to generate the check values. The independent program should emphasize correctness over speed. If it takes prime95 4 months to test an exponent near 10^7, our New Independent Slow Program (NISP) could easily spend 12 months on the job. So to be practical we might want to carry out the LL computation for only 10^5 or 10^6 iterations and use those incomplete residues for testing (just like the prime95 self check does). Here is something to think about. Say 50 years from now GIMPS claims to have found all mersenne primes with exponents below 1 billion. Some young math grad student is sitting around contemplating the beauty of mathematics and comes up with a theory for the distribution of Mersenne Primes, but the GIMPS results do not match her theory. What to do? Doubt the theory or doubt the GIMPS results? In order for future generations to trust the GIMPS results, the future will need to know enough about the software (versions 1 thru 18 and beyond) and the process used, to trust the results. The type of development process you describe will help encourage that trust. Brian Beuning Ken Kriesel wrote: > > I propose the following be considered, for each future version released > (and for the versions in heavy use currently): > 1. Code review by qualified volunteers. > 2. George and such other people as are qualified, determine which exponents > make good test cases, based on a review of the code. > 3. Volunteers with some cpu-power run LLtests and double-checks on the test > cases selected. > 4. Volunteers run randomly selected exponents LLtests and others run double- > checks of the same exponents simultaneously. Random selection may hit > a test case that's useful but was not identified as a separate case. Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne: Re: Mersenne Digest V1 #540
Henk Stokhorst wrote:
>I hope that one of those numbers that need to be redone does not turn into a cash
>winner. It would make the person who did the first attempt feel a little too silly.
>If I win $50,000 and it was previously assigned I will share part of it, $5,000
>(10%) to the misfortunate returner of a wrong residu.
Magnanimous gesture Henk. I too take the Stokhorst pledge to hand over
5k to anyone who previously searched a number that came back incorrectly
composite if I win the 50k. Another 5k to the GIMPS prize fund if I should
be so lucky. Uncle Sam gets the rest... {8-[{8^D spike
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne: V17 bug discovery and preventive measures
Since George Woltman found and announced the bug in V17 prime95 and its relatives, which invalidates Lucas-Lehmer tests started by V17 for p>2^22 (=4194304) with a nonzero shift count, I've been thinking about some possibilities for making such bugs less likely to reach the general GIMPS user and to have less impact if it does. First, let me say that I think George, as well as Scott Kurowski, have done an extraordinary job with both code development and project coordination. The Lucas-Lehmer test is absolutely unforgiving of error. Writing a program that produces a correct residue after hundreds or thousands of hours on a fast Pentiumxx is a remarkable achievement. Doing it efficiently is another. Coordinating thousands of people running it somewhat independently and on numerous operating systems is another. Once the problem was known, the action to minimize future cpu-time loss was apparently prompt and vigorous. Program versions of Prime95 and primenet were previously developed quickly when GIMPS as a whole was running out of exponents to test (when the limit of the code was 5,260,000 rather than 20,500,000) or when the primenet server was experiencing growing pains. Since we now have a wealth of exponents to be tested or retested, requiring a total expenditure of billions of cpu-hours, perhaps we could introduce a little more formalism into the program-validation process. I volunteered months ago to test 1 or 2 exponents in each runlength. Several have completed. Brian Beesley offered to double-check my results, and George has assigned them to Brian as double-checks. The nature of the just-discovered bug suggests that more test cases are in order. I propose the following be considered, for each future version released (and for the versions in heavy use currently): 1. Code review by qualified volunteers. 2. George and such other people as are qualified, determine which exponents make good test cases, based on a review of the code. 3. Volunteers with some cpu-power run LLtests and double-checks on the test cases selected. 4. Volunteers run randomly selected exponents LLtests and others run double- checks of the same exponents simultaneously. Random selection may hit a test case that's useful but was not identified as a separate case. Sequencing of this where possible would focus first on the exponent ranges already issued and next to issue from Entropia and the other primenet servers. Since this project is in a sense George's baby, I feel he has the right to ok or nix this. If he says ok, I volunteer to be the contact point for volunteers to enlist as either code reviewers, testers, or both. After a week or two I will summarize to George. Ken Ken Kriesel (resident of Madison WI, last year's #1 city and this year's #7) Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne: Re: Deletion of Intermediary files?
Hi all, At 02:12 PM 4/3/99 -0500, Matthew Thomas Ries wrote: >When you compare the version of the client to see if the >LL test must be performed again, are you checking to see when the exponent >was *assigned* or when it was *started*? Neither. In the save file itself is all the information I need. The last 32 bits of a v17 save file are the error count. The 32 bits before that are the "shift count". If the shift count is zero, then the LL test started in version 16. NOTE: version 16 save files are 8 bytes shorter than version 17 save files. Assuming I didn't make another mistake, version 18 should delete the save file if the file was generated by version 17, the exponent is above 4194304, and the shift count is non-zero. Hope that helps, George Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne: Questions re The bug
I receive the list, but don't normally read it. After glancing at a couple of messages today, it appears there is some type of fairly major bug. I run the NT version, as a service - so what do I need to do? --- Stephen Whitis Visit http://www.whitis.com for information about Delphi, NT4.0 software, and more. Support the anti-Spam amendment Join at http://www.cauce.org/ I won't do business with spammers, but I will report them, ridicule them, etc. Spam me at your own risk. Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne: Binary to Decimal Conversion
Attached is a Pascal Program that will convert a Binary Number of any length (currently 250 digits) to its Decimal Form. It does this by a "Decimal Search" on the high order digits. This is similar to a "Binary Search". If you want the executable program, just e-mail me at [EMAIL PROTECTED]. Milton L. Brown
Mersenne: Fw: Binary to Decimal Conversion
- Original Message -
From: Milton
Brown
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Saturday, April 03, 1999 11:51 AM
Subject: Binary to Decimal Conversion
Attached is a Pascal Program that will convert a
Binary Number
of any length (currently 250 digits) to its Decimal
Form. It does
this by a "Decimal Search" on the high order
digits. This is similar
to a "Binary Search". If you want the executable
program, just
e-mail me at [EMAIL PROTECTED].
Milton L. Brown
PROGRAM Binary;
{ By Milton L. Brown 3-15-1999
[EMAIL PROTECTED]
Converts a Binary Number of any length to a Decimal Number
-
Uses a "Decimal Search" on high order digits, similar to
a Binary Search.
Example Output:
Enter binary number here : 11101011000110100010101
1 2345 6789
}
LABEL line1, line2;
TYPE
iarray = array[1..1000] of integer;
MaxStg = string[250];
VAR st1, st2 : MaxStg;
r1, q1, twos : integer;
VAR a, b, len1 : integer;
i, j, k, out, carry, carry2 : integer;
a1, b1, c1, d1, e1, binary, answer : iarray;
log2 : real;
binary_d, number_d, jj, kk, current : integer;
FUNCTION chardig( k : CHAR) : INTEGER;
BEGIN chardig := ORD( k ) - 48 END;
PROCEDURE digit1( k : MaxStg; var a : iarray );
VAR i: INTEGER; BEGIN
FOR i:= 1 TO length(k) DO a[length(k)-i+1] := chardig(k[i]) END;
PROCEDURE initial; BEGIN
carry := 0; out := 0;
FOR i:= 1 TO 1000 DO a1[i] := 0;
FOR i:= 1 TO 1000 DO b1[i] := 0;
FOR i:= 1 TO 1000 DO c1[i] := 0;
FOR i:= 1 TO 1000 DO d1[i] := 0;
FOR i:= 1 TO 1000 DO binary[i] := 0;
END;
procedure clear; BEGIN FOR i:= 1 to 1000 DO answer[i] := 0; END;
PROCEDURE REMAIN(a1: iarray; var r1 : integer; var b1 : iarray); BEGIN
r1 := 0; j := 1;
FOR i:= len1 DOWNTO 1 DO BEGIN
twos := r1*10 + a1[i];
q1:= trunc(twos/2);
b1[i] := q1;
r1:= twos - 2*q1;
END;
END;
FUNCTION compare2(c1, binary : iarray):integer;
LABEL lend;
BEGIN
FOR i:= (4*len1) downto 1 do BEGIN
if c1[i] > binary[i] then begin compare2 := 1; goto lend; end;
if c1[i] < binary[i] then begin compare2 := -1; goto lend; end;
END;
compare2 := 0;
lend :
END;
PROCEDURE convert2(a1:iarray;VAR c1:iarray);
VAR carry1, carry2, in1, out : INTEGER; BEGIN
FOR k := 1 TO (4*len1) DO BEGIN
remain(a1,r1,b1);
c1[k] := r1;
FOR i:= 1 TO len1 DO a1[i] := b1[i];
END;
END;
BEGIN
log2 := 0.3010299957;
line1: initial;
WRITE('Enter binary number here : '); READLN(st1);
binary_d := length(st1);
number_d := trunc(log2*binary_d) + 1;
writeln(binary_d,' ',number_d);
digit1(st1,binary);
clear;
current := number_d;
len1 := number_d;
jj := number_d;
len1 := jj;
line2:
FOR kk := 1 to 10 do BEGIN
answer[jj] := kk;
convert2(answer,c1);
if compare2(c1,binary) = 1 then begin
answer[jj] := kk-1;
jj := jj-1;
goto line2;
END;
END;
writeln(st1);
FOR i:= len1 DOWNTO 1 DO BEGIN
IF (i MOD 4) = 0 THEN write(' ');
WRITE(answer[i]);
END;writeln;
GOTO line1;
END.
Mersenne: Deletion of Intermediary files / Bug #2?
After first hearing about the bug on the Digest, I made backup copies of my intermediary files and made the upgrade. My home computer did reset to iteration 0, but the other two did not. I don't believe the exponents they had began LL testing in v16, so I was a little puzzled as to why the LL tests were still intact. The following just occurred to me while reading the Digest that arrived today. When you compare the version of the client to see if the LL test must be performed again, are you checking to see when the exponent was *assigned* or when it was *started*? This is the only reason for why those tests are proceeding that I can think of. --- -Matthew Ries Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Digest V1 #540
Mersenne DigestSaturday, April 3 1999Volume 01 : Number 540 -- Date: Thu, 1 Apr 1999 18:08:50 -0800 From: "Robert Clark" <[EMAIL PROTECTED]> Subject: RE: Mersenne: RE: IMPORTANT: BUG IN VERSION 17 PRIME95 I am sure you must feel terrible, George. So although it may not completely make you feel better, I just want you to know how much I appreciate the incredible effort you have and are continuing to make on this project. You have accomplished a great deal, and the whole project has been handled in a completely professional manner. There are thousands of us now searching for Mersenne primes who would otherwise not have had the chance, and I imagine virtually all of us are greatful to you for that. Most of my machines are already converted. Let's find more! Best regards, Robert Clark Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm -- Date: Thu, 1 Apr 1999 21:20:01 -0500 From: Bryan Fullerton <[EMAIL PROTECTED]> Subject: Re: Mersenne: IMPORTANT: BUG IN VERSION PRIME95 17 On Thu, Apr 01, 1999 at 06:04:50PM -0500, George Woltman <[EMAIL PROTECTED]> wrote: > > After upgrading, you will get error messages that look like this: > Error reading intermediate file: p6180331 > Renaming intermediate file q6180331 to p6180331. > Error reading intermediate file: p6180331 > This is normal. Prime95 must discard the incorrect version 17 > save files. Will it also discard version 17 save files for double checks? I'd assume so, but thought I'd ask just to make sure. Bryan - -- Bryan Fullertonhttp://www.samurai.com/ Owner, Lead Consultant http://www.feh.net/ Samurai Consulting http://www.icomm.ca/ "No, we don't do seppuku." Can you feel the Ohmu call? Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm -- Date: Thu, 1 Apr 1999 19:25:00 -0700 From: "Aaron Blosser" <[EMAIL PROTECTED]> Subject: RE: Mersenne: RE: IMPORTANT: BUG IN VERSION 17 PRIME95 > Alas, it is not an April Fools joke. > > Sorry again, > George Don't sweat it George. So, just to clarify, if there were any results of exponents under ~4.2M, they should be okay, meaning if I used 17.2 to doublecheck numbers in the 2M range, they're fine? It's only all those ones higher done with 17.x that need to be done again? And was it 17.1 *and* 17.2, or just 17.2? These things happen. Better to find out now than another couple months down the road. I did notice that after upgrading on my machines, even those that were double-checking exponents in the 2M range started over. Is that just to be safe? Should we consider triple-checking all those that were double-checked with 17.x? At least trial-factoring wasn't affected! :-) Will Scott be able to simply root out all tested numbers done with 17.x from his database, or will they only start to show up as double-check tests in a few months? Personally, I set my machines to double-check in the meanwhile...until this is all sorted out. Aaron Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm -- Date: Thu, 1 Apr 1999 19:16:32 -0800 From: "Scott Kurowski" <[EMAIL PROTECTED]> Subject: RE: Mersenne: IMPORTANT: BUG IN VERSION PRIME95 17 > I've asked Scott to change Primenet to assign double-checking > work to version 17 clients in the future. PrimeNet's assignment rule was put into place shortly after George's message. v17 clients asking for LL tests will get double-checking. Folks, we now have more continuous CPU time on LL tests than ever before in all of human history. And recently new members are joining six times faster than usual, over 120 per day. GIMPS will bounce back quickly. Best regards, scott Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm -- Date: Thu, 01 Apr 1999 22:23:51 -0500 From: George Woltman <[EMAIL PROTECTED]> Subject: Mersenne: Re: More on v17 bug Hi once again, At 09:59 PM 4/1/99 -0500, Bryan Fullerton wrote: >I just downloaded the new mprime.tar.gz from the entropia.com FTP site, >and it appears to still be v17.1.2 - the binaries are dated Nov 3, 1998. Oops. It's been a long day. I'm uploading the proper ones now. Bryan wrote earlier about deleting of v17 save files when you are double-checking and uprgade to v18. The answer is yes you will lose your good v17 work. If you are double-checking, please wait to upgrade. I'll release version 18.1 that will toss the old save file only if you are testing an exponent above 4.19 million. Scott just contacted me. To have the server redirect a
Re: Mersenne: Recent Happenings
At 09:42 AM 4/3/99 -0600, kilfoyle wrote: >yep yep yep George... the search continues. It is not deterred by a small >bug. I'm not deterred either. In fact, I added a second machine since I found out about the bug. +---+ | Jud McCranie [EMAIL PROTECTED] | | | | "We should regard the digital computer system as an | | instrument to assist the number theorist in investigating | | the properties of his universe - the natural numbers."| | -- D. H. Lehmer, 1974 (paraphrased) | +---+ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Re: Mersenne: Goodbye...
I have to disagree here. People will be studying this project many years in the future. This little faux pas is part of the project and adds to the total work required to do it (Did anyone REALLY think a project this BIG would come off error free???). For historical purity reasons, I say leave the work values as they are. At work I am a developer for the worlds biggest computing software upgrade (The Boeing DCAC/MRM program, "Over $2 Billion served"). Compared to this project, DCAC/MRM is a freakin' circus. Keeping good configuration management is the hardest thing to do (Even harder than raising kids???). Guys like George Wotlman and Linus Torvalds should be given medals for their magical ability to keep things under control while keeping things productive. Lets keep things accurate! -Chuck On Sat, 3 Apr 1999 [EMAIL PROTECTED] wrote: > A small suggestion. It's only a small point, and would only bother people who are > overwhelmingly worried by rankings, but... > > Could we not credit those users who have had their intermediate files wiped as a > result of updating to v18 for the work carried out up to the last time they > checked in the exponent to PrimeNet? > > e.g. if someone was working on an exponent around 5 million (256K FFT) and they > had checked in to PrimeNet that they were at exponent x with v17, but started the > run again with v18, they should be credited with 0.776*x P90 CPU seconds for the > "lost" work. > > This could be seen as a sort of "good will" gesture to those who have lost work. > After all, if they let the exponent continue to the end & report it before > upgrading, they would get full credit, for a bad result. > > Though, quite honestly, there are more urgent things to do, like knocking the > database back into shape. However, if the server logs contain suitable > information, I'm sure they could be scanned to retrieve the information neccessary > to implement my suggestion. > > Scott, if there's any way you could send me a description of the log file format, > (and perhaps a small extract), I could look at writing a program which you could > use to do the processing, but I won't be able to look at it for a week or two. > > Regards > Brian Beesley > > Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm > -- ~~~ : WWW: http://www.silverlink.net/poke : Boycott Microsoft : : E-Mail: [EMAIL PROTECTED] : http://www.vcnet.com/bms: ~~~ Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Re: Mersenne: Recent Happenings
yep yep yep George... the search continues. It is not deterred by a small bug. Bugs are always lurking. I also thank George for his years of effort.. THANKS GEORGE!! Michael Chad Davis wrote: > Hi, > I'd just like to chime in with what I'm sure must be the feelings of > most of us here. We understand that accidents happen, bugs creep in, > especially ones that are subtle and hard to detect. Without George's > expertise and long hours spent programming and organizing the effort, very > very few of us would be searching for Mersennes. It continues to be a highly > enjoyable experience, so I want to take this opportunity to echo Robert, > Jean-Yves, and others in saying Thank You George. > > Just For Fun, > Chad > > > Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Re: Mersenne: Goodbye...
A small suggestion. It's only a small point, and would only bother people who are overwhelmingly worried by rankings, but... Could we not credit those users who have had their intermediate files wiped as a result of updating to v18 for the work carried out up to the last time they checked in the exponent to PrimeNet? e.g. if someone was working on an exponent around 5 million (256K FFT) and they had checked in to PrimeNet that they were at exponent x with v17, but started the run again with v18, they should be credited with 0.776*x P90 CPU seconds for the "lost" work. This could be seen as a sort of "good will" gesture to those who have lost work. After all, if they let the exponent continue to the end & report it before upgrading, they would get full credit, for a bad result. Though, quite honestly, there are more urgent things to do, like knocking the database back into shape. However, if the server logs contain suitable information, I'm sure they could be scanned to retrieve the information neccessary to implement my suggestion. Scott, if there's any way you could send me a description of the log file format, (and perhaps a small extract), I could look at writing a program which you could use to do the processing, but I won't be able to look at it for a week or two. Regards Brian Beesley Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne: New version of PRIMEOS2
Hi all OS/2 users, Since also PRIMEOS2 and PRIMEEMX have been affected by the bug I have uploaded new versions of both programs to: http://www.xs4all.nl/~mfvl/prime These versions are (again) the ports of MPRIME V18.1.2 containing the mulmod corrections as mentioned on this list before. Everyone using the V17 port (Version 3.2.x) should upgrade. With kind regards, Michiel van Loon Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne: RE: Version 17 errors
Hi Greg, > It would be very helpful if there were a way to request, > from the Primenet server, a list of machines and the > version reported by their last result. This would make > administration of more than a few machines much > easier. Any possibility of this? Sure. If there is enough demand I can put up a web page for this, but short of that please email me. Here are your v17 machines: machine_id - aup bdc fuzzybutt gmab greg-home-p2 horntoad imcs monica qa webs_r_us And here are your v16 machines: machine_id - dan demo devnts2 greg greg-home-px ozzie popmail prime1 prime2 prime3 swg winterm Best regards, scott Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
