[QUOTE=gd_barnes;325275]No I used mine. Since there were no primes found, it would not have made any difference.[/QUOTE]

True I suppose.

So...
S488 done, 2 k removed, 7 k remain
31*488^30060+1 is 3-PRP! (62.7704s+0.0026s)
35*488^58539+1 is 3-PRP! (242.7702s+0.0047s)

residue attached.

and, as said in the 'should be run first ' said, taking s283 from 10k to 25k

[QUOTE=firejuggler;326478]So...
S488 done, 2 k removed, 7 k remain
31*488^30060+1 is 3-PRP! (62.7704s+0.0026s)
35*488^58539+1 is 3-PRP! (242.7702s+0.0047s)

residue attached.

and, as said in the 'should be run first ' said, taking s283 from 10k to 25k[/QUOTE]

Can you provide the sieve file that you used?

Did you know that there was a sieve file link on the Sierp reservations page? Edit: I have now removed it from the page but it is attached here. It was sieved much deeper at the lower n and so would have saved you significant time.

I used the one on the crus webpage, which is the same as this one.
As for S283, didn't found one, sieved myself up to 35e9, and found an handfull of prime already

[QUOTE=firejuggler;326544]I used the one on the crus webpage, which is the same as this one.
As for S283, didn't found one, sieved myself up to 35e9, and found an handfull of prime already[/QUOTE]

You might want to rethink that. You couldn't have used the one on the CRUS web page. You have residues for many more k/n pairs than are in the sieve file. There are 15,404 residues in your results file and 13,909 tests in our sieve file. In order to get a direct comparison, I had to combine the 3 files that you posted, remove the blank lines and other non-residue lines, remove 15 duplicate residues where the same k/n pair was tested twice, and finally sort the whole thing by n and k.

For reference, here are some examples of tests that you did that are not in our sieve file:
[code]
141*488^25004+1 is composite: RES64: [776E5A7CA543F381] (51.1039s+0.0034s)
106*488^25008+1 is composite: RES64: [53B4EAD541DC0339] (50.5412s+0.0027s)
31*488^25020+1 is composite: RES64: [87E7FCE22CDB6D20] (26.3808s+0.0011s)
128*488^25027+1 is composite: RES64: [021D1A6A1060115F] (51.3817s+0.0011s)
31*488^25040+1 is composite: RES64: [8ABB114C1FFC12C8] (51.3090s+0.0088s)
8*488^25043+1 is composite: RES64: [3431847254566AB0] (51.4703s+0.0126s)
[/code]

That's 6 unnecessary tests in the first 10 (sorted) lines of your combined file.

So my question is, what sieve file did you use and how deep did you sieve it? The duplicate tests where the same k/n pairs were tested twice, the extra tests throughout the file, and the fact that there are some tests that you didn't do for n>93000 (taking into account the primed k=31 & 35) makes me greatly question the integrity of the entire testing.

I've been checking things a little closer lately because I've found a few bad sieve files floating around here and there.

Likely this entire run needs a doublecheck.

I see.My computer must have buggged somewhere.
I apologise to everyone for the extra - work it involve.
I'll check my S283 run more carefully.

[QUOTE=firejuggler;326562]I see.My computer must have buggged somewhere.
I apologise to everyone for the extra - work it involve.
I'll check my S283 run more carefully.[/QUOTE]

You are missing my point. If your computer has a bug, that would not cause it to do extra tests. It might possibly miss a prime, report a prime that is actually a composite, or give bad residues. It would not just pull random tests out of thin air. My point is, this appears to be a user error, not a computer error. It could not have tested what you did not load into it.

It's possible that your computer is fine and that you gave it a different sieve file. Do you have the file that you gave it? If not, the range will need a doublecheck.

I was able to find a part of them. So the range will have to be double checked partially... at least k 31 and 35 are out.
hopefully everything won't have to be rerun. (25k to 58-60k and about a third of the expo above 93k... I think the one contained dubbed 3300_1)
once again, I apologize for the extra work it will ask.

[QUOTE=firejuggler;326592]I was able to find a part of them. So the range will have to be double checked partially... at least k 31 and 35 are out.
hopefully everything won't have to be rerun. (25k to 58-60k and about a third of the expo above 93k... I think the one contained dubbed 3300_1)
once again, I apologize for the extra work it will ask.[/QUOTE]

I could not make sense of these. None of them have k=31, 1 of the 3 has k=35, they all have different n-ranges, there is 2 different sieve formats, and there is 2 different sieve depths, which overlap each other on n-range. There is no way that I can match anything up. I will doublecheck the whole range. It will take ~3 days on my machines.

The reason why you had so many more tests is that the files were badly under-sieved to only P=338M (vs. 1T for the CRUS file).

In the future, if you are not using a CRUS sieve file, I'm going to ask that you provide me one sieve file that represents all of your tests. The tests in the results/residues file should match the tests in the sieve file with the exception of primed k's.

Also, I'm going to ask for a single results/residues file (n>25K only please) that is sorted by n and k. If your results for one base are on several machines, you'll need to merge them all into one file and then sort them before posting them. (This should get rid of all of the blank lines and non-residue comment lines.) It takes me a while to sort things myself and even longer if it doesn't match the sieve file. The project takes long enough to administer without having to sort everyone's work. Don't worry, you're not the first person I've had to ask to do this.


Thanks,
Gary

Reserving R488 to n=50K.

Reserving R281 and R327.