mersenneforum.org

mersenneforum.org (https://www.mersenneforum.org/index.php)
-   Sierpinski/Riesel Base 5 (https://www.mersenneforum.org/forumdisplay.php?f=54)
-   -   All things doublecheck!! (https://www.mersenneforum.org/showthread.php?t=6289)

axn 2006-09-02 12:41

[QUOTE=michaf;86115]I suspect that all known residues will be in by now.[/quote]
Quite possible. But another week won't cause much harm one way or the other. Just wanted to give everyone a chance to get their work recorded as "first".

[QUOTE=michaf;86115]I suggest we indeed open the pairs without residue for first time testing then (if only it looks weird that we haven't tested some low pairs...)[/quote]
Agreed. We'll let the Sierpinki's continue to 20k. Probably we can do the same for Riesels also. However I would still like to wait another week for everyone to have one last chance to submit their hidden residues :smile: After that, we can go full steam ahead (:unsure: behind?)

[QUOTE=michaf;86115]As far as the double check goes, I think we need to get it up to a point where we can say that we have at least confidence that no little primes are left in there (let's say that is all below 20k)[/quote]
Masser has already done this for Sierpinskis, and I have done this for Riesels. So we can safely say that there are no "small" primes left behind. So the main focus is to get all results recorded systematically.

[QUOTE=michaf;86115]And besides, I don't think running the checks upto 20k will take too much of a time; already on 6k now[/QUOTE]
It is fun to watch a single day's testing to mess up all the graphs, isn't it? :wink:

michaf 2006-09-02 12:43

I mostly agree to your post two above; ( you type too quick....)

I think we DO have a good go at the prp-error rate, be it human or computational... waaay too many primes were missed.

But then, get your DC efforts in LLR-Net, so it shows what has been done :mellow:

axn 2006-09-02 12:46

[QUOTE=ltd;86117]Error rates are not a problem with these short running tests. Even at PSP where n is>2880000 there is no need for DC.

It is more about tests never done due to errors.

I did not know that there has been an effort by masser to check the low sierpinski numbers eles i would not have released them.

I promise next time i will ask before doing something stupid.:wink:

Lars[/QUOTE]
Meh! I wanted to do that myself. As michaf noted, the "min n untested" column has been bugging me to no end. In fact I would suggest that you go ahead and do the same for Riesels also. After one week, we can release 20k < n < 100k for all k's (both S & R).

You're right about the need for dc - which is why I am hesitant to start a new queue just for dc in the LLRNet server. But it would be nice to have residues for all first time tests.

michaf 2006-09-02 12:48

[QUOTE=axn1;86118]

It is fun to watch a single day's testing to mess up all the graphs, isn't it? :wink:[/QUOTE]


Yeah! :showoff:

pity it will be off the charts again in 30 days...

axn 2006-09-02 12:50

[QUOTE=michaf;86119]But then, get your DC efforts in LLR-Net, so it shows what has been done :mellow:[/QUOTE]

If you look at the "DC min untested" column, you'll see that the dc effort is indeed being recorded there. Once I have sweeped the Riesels to 55k, I'll get the residues updated in there. However, these are currently not considered as first time tests -- hence the "min n untested" column will stay where they are.

I know, I know, it is all backwards :confused: But at least, I hope you understand what is going on, right?


PS:- Yeah, sometimes I do type too fast :razz:

ltd 2006-09-02 12:51

[QUOTE=axn1;86120]Meh! I wanted to do that myself. As michaf noted, the "min n untested" column has been bugging me to no end. In fact I would suggest that you go ahead and do the same for Riesels also. After one week, we can release 20k < n < 100k for all k's (both S & R).

You're right about the need for dc - which is why I am hesitant to start a new queue just for dc in the LLRNet server. But it would be nice to have residues for all first time tests.[/QUOTE]

I will release the low n for riesel now.

Lars

michaf 2006-09-02 12:54

[QUOTE=axn1;86120]
You're right about the need for dc - which is why I am hesitant to start a new queue just for dc in the LLRNet server. But it would be nice to have residues for all first time tests.[/QUOTE]

What we can do too, once we have all the first time residues, is to set up an occasional double-check into llr-net, every 100 numbers there is 1 dc or summat like that. At least we then do have the opportunity to check the error-rate, and it will not get a lot of load on us either (just get geoff to make his sieve run 1% faster again, and we will shave the time off that way :wink: )

michaf 2006-09-02 12:59

Can LLR-net be set up like this:

for each residue above 100k, release one from the lower part?

that way we still move up, and we get all the residues eventually as a bonus.

masser 2006-09-02 15:53

Hi all,

I'm out of town until Tuesday, so I won't be able to send the residues until then. (Expect them Tuesday evening, axn1) All of the Sierpinski's with n < 37 k have been doublechecked by me. In another 2 weeks I'll complete the double check to n = 65 k.

I have no problem with any of the double check candidates being placed in the LLRNET queue. If it turns out that we're triple-checking some candidates, what harm can be done? The tests are reasonably short on faster machines and it's always possible that I made some "human error" somewhere and we missed a prime again. (unlikely, but possible)

At any rate, the Sierpinski double check candidates with n > 65k should certainly be entered into the queue sometime in the near future.

masser

konrad127123 2006-09-02 20:43

I won't be home until the 15th and so can't send in my residues untill then.

ltd 2006-09-04 16:28

So far we have done 43295 double checks and all result were identical.:smile:

Is it possible that we split up the double check things into another thread?

Lars


All times are UTC. The time now is 23:24.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.