Choose your own K and work on finding a top-5000 prime!

[kar_bon]

Sure, this Riesel k seems not done before (upto n=50k by me to cover the SophieGermain) and there're also no further entries in the Top5000 database.

[Nescro]

The k value of 3382599 has now been searched up to 200,000. Throughout this process I have found a total of 12 primes. The first 50,000 was sieved to p = ~240 billion, and the last 100,000 to p = ~150 billion. I plan on searching higher. I may wait until 500k to post the next update. Thank you for your help :)

54947
57479
61748
65944
68904
74729
85652
95728
119717
120329
139875
157759

[pepi37]

Originally Posted by Nescro

The k value of 3382599 has now been searched up to 200,000. Throughout this process I have found a total of 12 primes. The first 50,000 was sieved to p = ~240 billion, and the last 100,000 to p = ~150 billion. I plan on searching higher. I may wait until 500k to post the next update. Thank you for your help :)

54947
57479
61748
65944
68904
74729
85652
95728
119717
120329
139875
157759

One rule you must follow ( for your own good) : you should sieve much deeper as you go up with exponents.

[Nescro]

Yea that makes sense, thanks for the explanation. I just thought that it was taking longer to remove candidates with the sieve than it took to test each one with LLR tests. In the future ill try to sieve higher. Thanks for the tip :)

[carpetpool]

Originally Posted by pepi37

One rule you must follow ( for your own good) : you should sieve much deeper as you go up with exponents.

True. Or until the rate at which candidates are being removed is less than a single LLR test.

[Happy5214]

My work filling in the RPS 9th Drive k's has reached n=300k. I've attached the primes here, and I will also post them (and the smaller primes for these k's) to Prime-Wiki.

[Dylan14]

k = 50171 reached 2.5 M, no primes found, continuing with the deep file provided to me from yoyo. Residues from the 1.5-2.5M range attached.

[storm5510]

Originally Posted by pepi37

One rule you must follow ( for your own good) : you should sieve much deeper as you go up with exponents.

Ditto.

By deeper, he means higher, as in trillions. I never sieve below three-trillion, and have gone as high as five-trillion. Depending on your hardware, this can take several days. The more terms you can remove, the less time you will spend testing.

[pepi37]

Originally Posted by storm5510

Ditto.

By deeper, he means higher, as in trillions. I never sieve below three-trillion, and have gone as high as five-trillion. Depending on your hardware, this can take several days. The more terms you can remove, the less time you will spend testing.

Sweet spot is thousand trillions is a quadrillion :) Especially if it is done by external source (YOYO) , and will in total remove more then few more percent of total sieve size.
And that is important if you work with huge candidates.

[storm5510]

Originally Posted by pepi37

Sweet spot is thousand trillions is a quadrillion :) Especially if it is done by external source (YOYO) , and will in total remove more then few more percent of total sieve size.
And that is important if you work with huge candidates.

Not everyone has, or wants, access to YoYo@home. I have an account, but do not use it. It runs what it wants to run and not what I want it to run, and on my GPU, not theirs.

I rarely run any k's longer than five digits. Based on the formula's for calculating digits, larger k's would make little difference. n's, on the other hand, would make really large differences. Some here have the CPU horsepower to run really large n's in rapid succession with LLR. I do not. Above 700K, the performance drop-off is quite pronounced on my i7. It would be nice to run these on my GTX 1080, but that option is not available, as far as I know.

[pepi37]

Originally Posted by storm5510

Not everyone has, or wants, access to YoYo@home. I have an account, but do not use it. It runs what it wants to run and not what I want it to run, and on my GPU, not theirs.

I rarely run any k's longer than five digits. Based on the formula's for calculating digits, larger k's would make little difference. n's, on the other hand, would make really large differences. Some here have the CPU horsepower to run really large n's in rapid succession with LLR. I do not. Above 700K, the performance drop-off is quite pronounced on my i7. It would be nice to run these on my GTX 1080, but that option is not available, as far as I know.

Proth2.0 run on GPU for base2
https://github.com/galloty/proth20