0x results...

[Mike]

What happens to the exponents with only "0x" as the LL test result? Are they going to be re-tested?

[dave_0273]

I noticed these strange residues a little while back and mentioned it in the data forum somewhere. However, if you get a list of all exponents with dodgy resiudes, and compare it to lucas_v.txt, they have all already had 2 OTHER sucessful double checks.

I would have looked into it more, but seeing as though they were already exponents that have been sucessfully doublechecked, I didn't really see much point.

I was a couple of months since i checked this last, It is probably time that I checked it again and made sure that any new ones reported do have 2 sucessful double checks.

[jinydu]

Why do all residues start with 0x anyway?

[justinsane]

0x signifies that a number is in hexidecimal

[Mike]

Originally Posted by dave_0273

I was a couple of months since i checked this last, It is probably time that I checked it again and made sure that any new ones reported do have 2 sucessful double checks.

Yes, I was looking at the cleared.txt list, and noticed that there's 15-20 of them, coming from 2 users primarily. I remember one of them was "Dummy_Results" (Tell you something, eh?).

[dave_0273]

I don't know all the uses for the dummy acount, but one thing that it is used to it trying to trick the server into thinking a result has been submitted for that exponent. Let me try to expain this (and could someone please correct me if I don't get this quite right)

On a very rare occasion, the server assigns an exponent for an LL test when it already has a factor found for that exponent. To try to stop that user from doing a useless LL test, a dummy resisude is submitted to primenet. The server thinks that it has a result, and when the user contacts primenet with the "factored" exponent, the server kicks it out of it worktodo file and gives them another to LL test.

I am pretty sure that this is pretty much how it works, I may be slightly off though.

[Mike]

If that's the case, then we just need to check the following exponents again:

9046523 64 D 0x 12-Sep-03 13:00 diamonddave finrad.dc
9061981 64 D 0x 13-Sep-03 15:01 diamonddave finrad.dc
9062957 64 D 0x 13-Sep-03 19:10 diamonddave finrad.dc
9096713 64 D 0x 17-Sep-03 04:30 diamonddave finrad.dc
9097853 64 D 0x 17-Sep-03 12:47 diamonddave finrad.dc
9103049 64 D 0x 18-Sep-03 02:55 diamonddave finrad.dc
9105823 64 D 0x 19-Sep-03 00:04 diamonddave finrad.dc
9110279 64 D 0x 20-Sep-03 01:52 diamonddave finrad.dc
9138043 64 D 0x 21-Sep-03 14:02 diamonddave finrad.dc
9139289 64 D 0x 22-Sep-03 02:25 diamonddave finrad.dc
33257209 68 D 0x 08-Sep-03 14:17 Pakka werk


I notice that they're all double checks o.O

[patrik]

All of those except the last one have already had two matching double checks. They are in the last lucas_v.txt file. (See the links at the bottom of http://www.mersenne.org/status.htm.) Since 0x doesn't match the other returned residue of 33257209 (in hrf3.txt; but the residue itself is not there), it will be released for a triple check in due time. BTW, the error code of the test in hrf3.txt looks terrible, so it will probably require a quadruple check.

[tom11784]

you say the error code looks horrible - is it my machine?
tom11784/desktop
just curious if it's me - also what is this horrific code?

[dave_0273]

The line from hrf3.txt that you want is

33257209,lmurray,933,WY1,00040229

From my post on "data on error codes" in the data forum, I found that no good result has ever been returned with that error code.

The error code 00040229 shows that there were...

29 SUM(IMPUTS) != SUM (OUTPUTS) errors
2 round off > 0.4 errors
4 ILLEGAL SUMOUTS errors

[tom11784]

trust me - my machine had worse
i don't have the hrf3.txt file to pull my machines line from, but it was really bad