repost:

Searched k=6073 to 500k.
Primes for exponent: 2967 and 59931
Unreserving 6073.

I see behind k=733 No Primes Left Behind Drive #14 from a few years ago.

I like to reserve k=733 and drive it a little further.

I'd like to reserve k=11340615

I'd like to reserve k =1501946985.

I'd like to reserve k=8191

I'd like to reserve k=32767

I reserve k=8515 :smile:

Reserving k=2017 :smile:

Reserving and working on k=146921775

Quick update on k=146921775.

Found 6 more primes for n=50k-100k, so in total 102 primes for n=0-100k.

Now working from n=1.29M up.

Can I reserve 6371?
No primes in Caldwell's base.
Interesting that its twin 6373 has prime.
[SPOILER]Can somebody explain, why so many Proth primes for k=6371?[/SPOILER]
Pre-thanks.

You may. It has primes at n = 38, 182,374,430. See rieselprime.de, menu "riesel data".
Someone checked it (and all k < 10,000) to n=10000 years ago to seed those web pages.

[QUOTE=unconnected;450202]Reserving k=2017 :smile:[/QUOTE]

Completed to n=6M and released. One prime - 2017*2^3292325-1.

Status for k>300 I've been testing:
2055 and 2085 are complete to 1025k, which I believe is the point where they joined one of the megabit drives. There had been a gap in the 607-620k range. I am not testing these, but was previously doing so in the under-1M range years ago, so I filled the gap when I discovered it.
2115 is complete to 1.56M.
2145 complete to 1.36M.
2175 complete to 1.33M.
All 5 of these had a gap from 607k to 620k, and filling that gap produced one prime (posted in the small primes thread, 2115@607390).
405 is complete to 1.72M.
443 is complete to 3.31M.

releasing k=8515 @ n=1526469

Reserving and working on k=17849 if no one else has taken it yet.

k = 17849 has reached n = 1M. Primes and residues were posted to the "Post small primes..." thread.
I am releasing this k, and reserving k = 17851.

k = 17851 reached n = 500k, and the primes and residues were posted in the "Post small primes..." thread. I am releasing this k.

Taking k = 17849 from n = 1 M.

Reserve 1501946985.
Grotex.

k = 1501946985 reached n = 100k, and get primes:
1501946985*2^52613-1
1501946985*2^67832-1
1501946985*2^80577-1
1501946985*2^84024-1
1501946985*2^86544-1
now going to n = 200k

[QUOTE=Grotex;488954]k = 1501946985 reached n = 100k, and get primes:
1501946985*2^52613-1
1501946985*2^67832-1
1501946985*2^80577-1
1501946985*2^84024-1
1501946985*2^86544-1
now going to n = 200k[/QUOTE]

k = 1501946985 reached n = 200k, and get primes:
1501946985*2^107544-1
1501946985*2^142461-1
I release this k

2641908225
 

Reserving 2641908225
Pre-thanks

[QUOTE=Dylan14;472977]Taking k = 17849 from n = 1 M.[/QUOTE]

Update on this search: I have sieved a file up to n = 2M and am testing it.
Has anyone worked on k = 50171 since amphoria released it in 2007 at n = 1.5 M? If not, I'll take it.

For lack of a better place to post my ongoing reservations, I'll dump them here. The mods can move this post if necessary.

I'm reserving:[list][*]All Woodall and near-Woodall k's > 10k with gaps below the (near-)Woodall prime to fill in said gaps:[list][*]197673[*]251749[*]454483[*]582833[*]586085[*]665127[*]667071[*]938237[*]1183953[*]1195203[*]1268979[*]1467763[*]8508301 (to n=4M only)[/list][*]All k's from the RPS 9th and 10th Drives, 15k < k < 35k, n < 400k, not already complete for that n range. All k's from this range that I've filled in for n < 400k are listed in the Prime-Wiki. There are 120 k's to be filled in, which is probably too many to list here.[*]The following low-weight k's, to n=1M unless otherwise noted:[list][*]612509[*]671413[*]685183[*]686711[*]700057[*]963643 (currently at n=1.5M; sieved to n=2M; double-checking and then will continue until a prime is found)[*]10453199 (currently at n=2.5M; sieved to n=3.5M; double-checking and then will continue until a prime is found)[*]10813783 (double-check to n=780k; probably will continue to at least n=1M)[*]1665624349782373 (sieved to n=1.5M; this will find the n for the prime previously claimed to have been found)[/list][*]The following miscellaneous k's:[list][*]89925 (to n=630k; already sieved)[*]242417 (sieved to n=1M)[*]1549573 (to n=300k; already sieved)[*]7828821 (sieved to n=1M)[/list][/list]
All of these reservations, except for the RPS drive k's, are either already up on Prime-Wiki or will be shortly. The RPS drive k's will be posted along with the data from the respective drives at a later date.

I'll also tack on k=14549535 for 125k < n < 300k as a double-check.

Q.: Is there a good generalized way to search for available [I]k's[/I]?

This is what I do. I will use "9999" as an example. I will do an entire forum search for "k=9999." Then I would follow that was just "9999." If there are a lot of hits, I look at each and use my browsers' "Find on this page" feature to search. I check the "Top 5000" web site, and the Wiki Riesel Prime database.

RPS appears to stay below any Nash value < 1000. It is hard to determine what their [I]k[/I] ceiling is at any given time. NPLB, it is difficult to see what they are working on. That area is not updated often.

After all this, if I find nothing concrete, I assume any [I]k[/I] I search for is fair-game. If there are other places to look, I would like to know what they are. Bottom line: I do [U]not[/U] want to step on anyone's toes by running something another person is working on. End of story...

Take any k above 10001 and I am sure 99% you will not in that case step on anyone others theritory
Also you have other base then two and software to make sieve for any home project. In other words, you have near countess combination, choose one

NPLB only works on k=301 to 1001. See the PRPnet servers thread there to see exactly what test depth different k-ranges are at. In a synopsis, k=301-349 is at n=~2.7M, k=351-399 is at n=2M, k=401-599 is at n=~1.59M, and k=601-1001 is at n=~1.56M.

[QUOTE=gd_barnes;540906]NPLB only works on k=301 to 1001. See the PRPnet servers thread there to see exactly what test depth different k-ranges are at. In a synopsis, k=301-349 is at n=~2.7M, k=351-399 is at n=2M, k=401-599 is at n=~1.59M, and k=601-1001 is at n=~1.56M.[/QUOTE]

I looked at the front page: [URL]http://www.noprimeleftbehind.net/stats/index.php?content=port[/URL]. Most of what I saw sailed over my head. Thank you just the same. :smile:

As [B]pepi37[/B] suggested, I will stay above 10001.

There's quite a penalty for going above 10,000- you have to sieve yourself, and you can't get anywhere near the sieve depth of the primegrid files. You should estimate the size of the penalty yourself, to better get a sense of why you really ought to pick a couple k's below 10,000.

Stay above 1000 and you avoid the two main projects. 1000-2000 were all tested to some small depth, like 600k, back in the day; but you know that from the data pages.

If you want something basically untested, pick something between 2000 and 10000 and get on with it.

Storm if you decide to go upper from 10001, I can send your sieve file to YOYO, and you will get sieve done up to 5e15. It is not PG sieve depth, but that depth is OK ( in my opinion)

Alright,[B] [I]k[/I] = 10151. [/B]Nash = 584.

I prefer running the lightweights.

[QUOTE=pepi37]Storm if you decide to go upper from 10001, I can send your sieve file to YOYO, and you will get sieve done up to 5e15... [/QUOTE]

[U][I]n[/I] to 15e5 would be fine.[/U] I will not need it for a while. I am still running the upper end of [I]k[/I] = 22783. Four instances on two machines.

[QUOTE=VBCurtis]...If you want something basically untested, pick something between 2000 and 10000 and get on with it.[/QUOTE]

I am only 151 over. That is not too bad, I believe.

[QUOTE=storm5510;541004]Alright,[B] [I]k[/I] = 10151. [/B]Nash = 584.

I prefer running the lightweights.



[U][I]n[/I] to 15e5 would be fine.[/U] I will not need it for a while. I am still running the upper end of [I]k[/I] = 22783. Four instances on two machines.



I am only 151 over. That is not too bad, I believe.[/QUOTE]

Will be sent this weekend in new batch

[QUOTE=storm5510;541004]I am only 151 over. That is not too bad, I believe.[/QUOTE]

Under 10000 = sieve file already generated. No work needs to be done.
Over 10000, by 151 or 1 or any other number = work needed to make a sieve file.
"Not too bad" has nothing to do with it. There are sieve files nobody is running- just pick one of those.

[QUOTE=VBCurtis;541009]Under 10000 = sieve file already generated. No work needs to be done.
Over 10000, by 151 or 1 or any other number = work needed to make a sieve file.
"Not too bad" has nothing to do with it. There are sieve files nobody is running- just pick one of those.[/QUOTE]

I think these are the files I asked you about a while back. Several pages of archive links as I recall.

[QUOTE=storm5510;541004]Alright,[B] [I]k[/I] = 10151. [/B]Nash = 584.[/QUOTE]

[QUOTE=pepi37;540994]Storm if you decide to go upper from 10001, I can send your sieve file to YOYO, and you will get sieve done up to 5e15. It is not PG sieve depth, but that depth is OK ( in my opinion)[/QUOTE]

I've never had a sieve on my machine run past [I]p[/I]=1e14 before the removal time went above the average LLR testing time for the block (that record was for 8 [I]k[/I]'s of various Nash weights, n = [250k, 1.2M], using sr2sieve), and I've always thought any sieve deeper than more than a few trillion was overkill for most low-weight [I]k[/I]'s like storm5510's. I imagine my 10yo Core 2 Quad is much slower than newer machines, but is yoyo@home [I]that[/I] much quicker to be able to make up that large of a difference? If so, I have a few sieve files that could benefit from sieving to higher [I]p[/I]'s.

[QUOTE=Happy5214;541230]I've never had a sieve on my machine run past [I]p[/I]=1e14 before the removal time went above the average LLR testing time for the block (that record was for 8 [I]k[/I]'s of various Nash weights, n = [250k, 1.2M], using sr2sieve), and I've always thought any sieve deeper than more than a few trillion was overkill for most low-weight [I]k[/I]'s like storm5510's. I imagine my 10yo Core 2 Quad is much slower than newer machines, but is yoyo@home [I]that[/I] much quicker to be able to make up that large of a difference? If so, I have a few sieve files that could benefit from sieving to higher [I]p[/I]'s.[/QUOTE]


Just send me PM with your email : all will be arranged.



Sieve at yoyo@home is made by at least 150- 200 CPUS ( in peak was 800 )
All sieve is now done to at least 5e15, and much factors will be removed if start point is 1e14. Golden rule is : when sieve need same time to find factor, and LLR need same time to process factor sieve depth is correct, but core2 quad are old CPUs...

[QUOTE=Happy5214;541230]I've never had a sieve on my machine run past [I]p[/I]=1e14 before the removal time went above the average LLR testing time for the block.[/QUOTE]

I feel this is where deep sieving is self-defeating when it comes to time. My current [I]k[/I] is taking 96 to 104 seconds, with [I]n[/I] > 800,000, for each term on my i7 running a double instance. Running a second instance made virtually no difference in the required time.

This CPU has four physicals and four logicals. Each instance of [I]LLR[/I] is using three threads. The CPU runs at 85°C. This is the limit and keep the rest of the interface responsive.

For now, my rule-of-thumb is a removal rate >= 125 seconds. When [I]LLR[/I] reaches this, I "think" about stopping and moving on, but I do not always stop. I usually stop a sieve at this level though. I do the best I can with the hardware I have. It would be nice if I could use my GTX 1080 for this, but that capability has yet to come along.

If you run LLR single-threaded at those tiny n-values, you'll get much better production. LLR doesn't multi-thread well when FFT size is smaller than 128K * # of threads.

I'd wait until about n=2 million to bother trying 2 threaded operation.

[QUOTE=VBCurtis;541242]If you run LLR single-threaded at those tiny n-values, you'll get much better production. LLR doesn't multi-thread well when FFT size is smaller than 128K * # of threads.

I'd wait until about n=2 million to bother trying 2 threaded operation.[/QUOTE]

Running three threads on each did not work out very well. Doing so produced enough heat to cause the CPU to throttle back when the temperature went beyond 85°C. My older i5 might benefit by reducing it to one thread per instance.

n < 2-million. In theory, I could run four instances on this i7. However, I will keep it at two, single thread each.

Many thanks! :smile:

[U]I am going to lump these here as a group[/U]:

[I]k[/I] = 98475, Released.
[I]k[/I] = 22783, Released.

[I]k[/I] = 10019, Active. Testing to >= 1e6.
[I]k[/I] = 317605. Active, Testing to >= 1e6.

I will not be posing anything additional in the forums on this subject. Any updates I have will be in [B]kar_bon's[/B] [I]Wiki[/I] database [U]only[/U]. The active [I]k's[/I] above were taken from there. No reservations on either. There are enough unreserved there with low [I]n[/I] values to last a long time.

[QUOTE=storm5510;541751][U]I am going to lump these here as a group[/U]:

[I]k[/I] = 98475, Released.
[I]k[/I] = 22783, Released.
[/QUOTE]
How far did you test these?

[QUOTE=VBCurtis;541767]How far did you test these?[/QUOTE]

98475 to [I]n[/I] = 770,000.
22783 to [I]n[/I] = 855,000.

I was frustrated with the progress on a single thread. This was before I started experimenting with multiple instances on multiple machines. I know I did not sieve them deep enough. Probably < 750e9. Everything I sieve now is a single large batch to 15e11. I may go back and pick these up again and take them to [I]n[/I] >= 1e6.

update on k's
 

k = 50171 is at n = 2.055 M, no primes found, continuing. Will likely continue beyond 2.5 M, so if yoyo can sieve up a file for me (up to say, n = 10 M), that would be nice.
k = 17849 - I don't have an update here as the machine running this is over at school and I'm not there due to the virus situation.

[QUOTE=Dylan14;541968]k = 50171 is at n = 2.055 M, no primes found, continuing. Will likely continue beyond 2.5 M, so if yoyo can sieve up a file for me (up to say, n = 10 M), that would be nice.
k = 17849 - I don't have an update here as the machine running this is over at school and I'm not there due to the virus situation.[/QUOTE]

50171 will be sent this weekend 😊

update on k’s
 

k = 17849 is at n = 1.524 M, no primes found, continuing...
k = 50171 no change, machine that runs this k is being serviced, so no progress has been made.

[I]k[/I] = 22783 was tested to [I]n[/I] = 1e6 ending on 2020-04-28.
[I]k[/I] = 98475 is a future project which will also be ran to [I]n[/I] = 1e6, or above.

Update on k's
 

k = 17849 reached n = 2M. No primes found. Residues attached - k released.
k = 50171 is at n = 2.286 M, no primes found, continuing...

k = 3382599
 

Hello, I am new to the concept of manually searching. However, I did manage to search k = 3382599 from the previous n = 50,000 to n = 60,000. This was a test to see if I could take on the task of a bigger search. Now that I completed it. I would like to ask if I could search this value up to around 200k or maybe even higher?

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.

50-200k complete
 

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

[QUOTE=Nescro;548197]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[/QUOTE]


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

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 :)

[QUOTE=pepi37;548200]One rule you must follow ( for your own good) : you should sieve much deeper as you go up with exponents.[/QUOTE]

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

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

update
 

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.

[QUOTE=pepi37;548200]One rule you must follow ( for your own good) : you should sieve much deeper as you go up with exponents.[/QUOTE]

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.

[QUOTE=storm5510;549253]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.[/QUOTE]


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.

[QUOTE=pepi37;549271]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.[/QUOTE]

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 [I]k's[/I] longer than five digits. Based on the formula's for calculating digits, larger [I]k's[/I] would make little difference. [I]n's[/I], on the other hand, would make really large differences. Some here have the CPU horsepower to run really large [I]n's[/I] 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.

[QUOTE=storm5510;549296]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 [I]k's[/I] longer than five digits. Based on the formula's for calculating digits, larger [I]k's[/I] would make little difference. [I]n's[/I], on the other hand, would make really large differences. Some here have the CPU horsepower to run really large [I]n's[/I] 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.[/QUOTE]
Proth2.0 run on GPU for base2
[URL]https://github.com/galloty/proth20[/URL]

[QUOTE=pepi37;549308]Proth2.0 run on GPU for base2
[URL]https://github.com/galloty/proth20[/URL][/QUOTE]


[QUOTE]proth20 is a new highly optimised GPU application, created in 2020.[/QUOTE]There is a link for an older CPU version, but not the one above. :confused:

Hello, I would like to test primes for k=20020913 (my birthday date :smile:). Could somebody please guide me to how far sieve, and what program to use? I have Radeon VII, RTX 2080Ti, and Ryzen 9 3900X available for testing. I would also like to ask if there is any difference between searching in k=20020913 and k=2002913?

In case there isn't a difference, I reserve the k=20020913, and the other one is for the future me.

I suggest you make a short project out of n=1 to n=400k to find small primes, and then decide how large an 'n' you want to set up a sieve for.

For the small primes, srsieve or newpgen to create the sieve file, then sr1sieve because it's faster than the other two. One generally sieves until the average time to find a factor is equal to the LLR time for a candidate 70% of the way from n-min to n-max; in this example, that would be at n=280k.
The reason I don't give a sieve depth number is that the proper depth depends quite a bit on how many candidates remain in the sieve, which is a way of saying the weight of the k-value. Different k's have different patterns of small factors that eliminate a bunch of candidates, so some k's need sieve depths an order of magnitude larger than others.

LLR is the primality-testing program; there is a version for GPU, but it's best described as alpha-version quality. Rogue has srsieve2 package of programs, some of which are GPU-enabled; peruse that thread (or wait for someone who knows more than I do here) to see if you can sieve on GPU and test LLR on CPU.

Large sieve ranges are more efficient than small ones; after you run to 300k or 400k for the first sieve and test all those candidates, I'd make a second sieve that covers any range you are likely to ever test- 400k to 4M isn't crazy, but that's core-years of searching; 400k to 2M could be completed in a few months.
The second k will yield different primes, so "saving" that for future-you makes sense.
Happy hunting!

First prime, before any tests!
 

BTW, before any tests, I found 20020913*2^12-1 to be prime. I simply calculated the value and used an online tool ([url]https://primes.utm.edu/curios/includes/primetest.php[/url]) to find out whether it is prime.

[QUOTE=VBCurtis;549446]LLR is the primality-testing program; there is a version for GPU, but it's best described as alpha-version quality. Rogue has srsieve2 package of programs, some of which are GPU-enabled; peruse that thread (or wait for someone who knows more than I do here) to see if you can sieve on GPU and test LLR on CPU.[/QUOTE]

Mark Rodenkirch (rogue) has stated before that the discrete log algorithm used in srsieve2 (BSGS) doesn't really benefit much from the expanded parallelism provided by AVX or GPUs, so such versions of srsieve2 don't exist.

I meant the GPUs for LLR testing. Is there a program for GPU testing, not sieving? Especially if it had properties as gpuOwl, it would be really fast on Radeon VII.

[QUOTE=Viliam Furik;549554]I meant the GPUs for LLR testing. Is there a program for GPU testing, not sieving? Especially if it had properties as gpuOwl, it would be really fast on Radeon VII.[/QUOTE]

I don't think there is any Riesel-GPU application. Why not crunch Mersenne-PRP with gpuOwl on your Radeon VII?

I asked Yves Gallot about Proth on GPUs, downloaded and compiled the source and it was equal to 4 CPU cores, whereas Mersenne is like 40 cores :surprised:

[QUOTE=paulunderwood;549555]...Why not crunch Mersenne-PRP with gpuOwl on your Radeon VII?...[/QUOTE]

Unless I am way behind, the only form gpuOwl will accept would be [I]k[/I] = 1. There was no way to specify a higher [I]k[/I] the last time I looked at it. It would be nice if it would.

[QUOTE=VBCurtis;549446]LLR is the primality-testing program; there is a version for GPU, but it's best described as alpha-version quality.[/QUOTE]

[QUOTE=paulunderwood;549555]I don't think there is any Riesel-GPU application. Why not crunch Mersenne-PRP with gpuOwl on your Radeon VII?

I asked Yves Gallot about Proth on GPUs, downloaded and compiled the source and it was equal to 4 CPU cores, whereas Mersenne is like 40 cores :surprised:[/QUOTE]

[url]https://www.mersenneforum.org/showthread.php?t=14608[/url] describes llrCUDA, which is what I believe VB is referring to. There does not appear to have been any work on it since 2018, and it is definitely alpha-level. As the name suggests, it's CUDA-only.

llrCUDA works, I have been running one for months. But it's slow, much slower than a CPU in the same class .
I am getting 1.1ms per iteration on n=3.8M on a 1080TI
While the same n is getting 0.271 ms per iteration on 5 threads and 0.7ms on 1 thread on an i7-6700K

My work on filling in gaps for (near-)Woodall [I]k[/I]'s has reached [I]n[/I]=300k. Three primes were found:[list][*]8508301*2^261263-1[*]1195203*2^262935-1[*]8508301*2^296247-1[/list]
A prime for [I]k[/I]=197673 was found earlier.

The list of [I]k[/I]'s tested to [I]n[/I]=300k is:[list][*]197673[*]251749[*]582833[*]586085[*]665127[*]938237[*]1183953[*]1195203[*]1268979[*]1467763[*]8508301[/list]
Updates will be posted to Prime-Wiki shortly.

I'm also reserving [I]k[/I]=1993191 (the latest near-Woodall [I]k[/I]) for [I]n[/I] < 3986382.

I have completed the (near-)Woodall [I]k[/I]'s, except for [I]k[/I]=1993191, to [I]n[/I]=350k. I found 2 primes:[list][*]1268979*2^332833-1[*]197673*2^341268-1[/list]
pepi37 kindly ran a large chunk of the range, and he found the following 2 primes:[list][*]251749*2^333881-1[*]1467763*2^340379-1[/list]
The list of [I]k[/I]'s tested can be found in the previous post.

k = 50171
 

k = 50171 is at n = 2.945 M, no primes found, continuing...

k = 1549573
 

[I]k[/I]=1549573 has now been tested to [I]n[/I]=300k. The known prime at [I]n[/I]=260199 (on Prime Pages) was re-confirmed, and no new primes were found. I am releasing this [I]k[/I]. The LLR log is attached (it's version 3.8.24, so PRP residues instead of LLR).

I restarted the search for primes with k = 105105.

So far I have checked up to n = 395 000 and found 4 primes:
105105*2^328791-1
105105*2^333964-1
105105*2^358832-1
105105*2^387091-1

Also regarding k=20020913, I have found another prime:
20020913*2^862692-1

I will update those k's in Prime Wiki.

[QUOTE=Viliam Furik;554266]
So far I have checked up to n = 395 000 and found 4 primes
[/QUOTE]

Silly me... 5 primes. I forgot to mention n = 260723.

I was testing k = 1281979 for n<= 100000 and interestingly the first 10 n for which this is prime are prime themselves. After that unfortunately there's n = 1005 which obviously isn't. But the ratio of n being prime vs being composite continues to be very high for the remainder of the range.

Is that a known property of some k and is it known why it happens? Is there a connection to Mersenne?


Nothing like that on the Proth side, but there the n that yield primes seem to come in pairs of two that are close to each other (5-10% difference). Though it might just be the brain's inbuild pattern recognition going overboard. So I'll keep testing. If there's something the next n should be in the 3e5 range. ;)

1281979*2^n-1 has a [url='https://www.rieselprime.de/ziki/Nash_weight']Nash weight[/url] of 1789, so relatively low.
1281979 [tex]\equiv[/tex] 1 mod 3 so all primes of that sequence are only odd n-values.
k-values with 2 mod 3 can only produce primes with even n's, and k's divisible by 3 can produce primes with odd/even n-values.

1281979*2^n+1 has a low Nash weight of 847, so there should less primes for this sequence.

The [url='https://www.rieselprime.de/ziki/Liskovets-Gallot_conjectures']Liskovets-Gallot conjectures[/url] study the contribution of odd/even n-values of such seqs.
There exits k-values which never produce primes for any n-value like the Riesel problem.

PS: If your're done you can list the prime n-values in this thread and I can include those in the Wiki, both sides (Proth /Riesel) possible. Don't forget to give the search limits then.

kar_bon, I never really understood the Nash weight. It is an indicator for how many candidates remain after sieving? So I would think a low weight is good, since few candidates after sieving is favorable? What do I miss?

I don't know what is average number of primes in n < 1e5 range, but I think there were maybe 15 for this k. Is that so little? Proth was giving similar number of primes.

[QUOTE]If your're done you can list the prime n-values in this thread and I can include those in the Wiki, both sides (Proth /Riesel) possible. Don't forget to give the search limits then[/QUOTE]I'll do that. 0 <= n <= 1e5 is done for both Riesel/Proth. I don't have the results here, but will post this evening.


The main task I want to accomplish is finding a mega prime using Proth20, so I'm currently sieving 3320000 <= n <= 4100000 for Proth side. But I also plan to do the remaining smaller n values for both Riesel/Proth using LLR on CPU. I'll post them here in the future.

The less the Nash weight is the less candidates remain after sieving is correct, but also the less chance to find a prime: low Nash = less cand. = less primes.

You could choose a lower k-value which produce smaller test timings for same n-values as 1281979.
Check the Wiki for [url='https://www.rieselprime.de/ziki/Riesel_k%3DLow_weight']low weight[/url] k-values to see the difference. You could sieve and test some higher ranges to get a feeling of those.
Looking other tables in the Wiki and sorting by #primes or Nash could help, too.

So the number of primes per n decreases stronger than the number of candidates per n?


Here are the n values that produce Riesel primes:

[CODE]1281979 * 2^n - 1
0 <= n <= 20000

[B]3
7
43
79
107
157
269
307
373
397[/B]
1005
[B]1013[/B]
1765
[B]1987
2269[/B]
6623
7083
7365
10199
16219


bold values indicate primes[/CODE]I have completed the same for Proth side, but since it's a work in progress, I'll post once I'm at larger n.
[QUOTE]You could choose a lower k-value which produce smaller test timings for same n-values as 1281979.[/QUOTE]There's a longer story behind why I chose that k... :D

I have two computers at work I can use for crunching, both are using CPU for Primegrid projects. I want to keep it that way, because I like the conjecture solving. So the cheapest way to do more crunching would be to buy to mid-low-end GPUs such as the GTX 1650 and use those for other projects. Then I found out LLR on GPUs is considered a waste of time.

But - there's a new software Proth2.0 that apparently tests Proth primes quite efficiently on GPUs. So I decided to find Proth primes. But PG has three Proth prime subprojects and covers a lot of small k's... Around that time I discovered my birth date is a prime number and also large enough not to interfere with PG. Also that it's prime could result in the interesting combination of prime k, prime n and prime b. I know large k hardly change anything in regard to total digits but make computation slower and I also knew the Nash weight is not that high using nash.exe, but I will keep that k. If I find a mega prime with it it will at least be a somewhat rare k ... ;)

[QUOTE=bur;556433]So the number of primes per n decreases stronger than the number of candidates per n?)[/QUOTE]

Nope. But the opposite isn't true, either.

[QUOTE=VBCurtis;556443]Nope. But the opposite isn't true, either.[/QUOTE]But then I would say low weight doesn't really matter. Either I test 100000 candidates for a given k and find 10 primes or I test 10000 and find one. Then move to the next low weight k and in the end I end up with the same number of LLRs and primes. Just spread over more than one k. Is it like that?

We have no evidence otherwise, though some folks around here do think otherwise.

I test a couple low-weight k's as well as some of the highest; I like finding anomalies, but I don't think my choices are more prime-worthy per unit of search effort.

I looked into the matter why only primes show up as n for low n values. Here are some restrictions I found:

If [TEX]n \equiv 0 \textrm{ mod } 2[/TEX] the Riesel number will be divisible by 3 (n = 2, 4, 6, 8, 10, ...)
If [TEX]n \equiv 1 \textrm{ mod } 10[/TEX] the Riesel number will be divisible by 11 (n = 11, 21, 31, 41, 51, ...)
If [TEX]n \equiv 1 \textrm{ mod } 8[/TEX] the Riesel number will be divisible by 17 (n = 9, 17, 25, 33, 41, 49, ...)
If [TEX]n \equiv 15 \textrm{ mod } 20[/TEX] the Riesel number will be divisible by 41 (n = 15, 35, 55, 75, ...)
If [TEX]n \equiv 19 \textrm{ mod } 70[/TEX] the Riesel number will be divisible by 71 (n = 19, 89, 159, 229, ...)

There might be more. I am not sure though if this will rather hit composites than primes. The 2nd condition removes 11, 31, 41, 71, so it doesn't really seem like it.

Haha, I just realized this is probably trivial and occurs for every divisor... yes, I'm not that good at math. :)

Here are the n values for Riesel primes with k = 1281979 and n <= 100000


3
7
43
79
107
157
269
307
373
397
1005
1013
1765
1987
2269
6623
7083
7365
10199
16219
26143
32557
38165
47167
47863
70373
94723
95167

The (near-)Woodall [I]k[/I]'s listed in [url]https://www.mersenneforum.org/showpost.php?p=550539&postcount=363[/url], again except for [I]k[/I]=1993191, have been completed to [I]n[/I]=375k. The only prime found was 667071*2^373497-1.

Edit: Another prime, 667071*2^358286-1, was already reported (by me) to the Prime-Wiki in August, so I accidentally left it off here.

I've completed the remaining RPS 9th and 10th Drive [I]k[/I]'s with missing ranges from [I]n[/I]=300k to 325k. 18 primes were found, which are attached. It'll probably be until the end of 2021 before they're finished to [I]n[/I]=400k, the ultimate goal.

update 11/3
 

k = 50171 is at 3.883 M, is on hold for the moment while I do a Carol-Kynea reservation. Please keep it reserved to me.

8847
 

Reserving 8847

The (near-)Woodall [I]k[/I]'s listed in [url]https://www.mersenneforum.org/showpost.php?p=550539&postcount=363[/url], this time and in the future [I]including[/I] [I]k[/I]=1993191, have been completed to [I]n[/I]=400k. The primes for [I]k[/I]=1993191 have already been posted to Prime-Wiki and will not be listed here for the sake of brevity. (There are 26 total below [I]n[/I]=400k.) The following primes were found for the other [I]k[/I]'s:[list][*]667071*2^380058-1[*]1183953*2^384787-1[*]665127*2^385516-1[*]1268979*2^387863-1[/list]

[QUOTE=bur;556456]But then I would say low weight doesn't really matter. Either I test 100000 candidates for a given k and find 10 primes or I test 10000 and find one. Then move to the next low weight k and in the end I end up with the same number of LLRs and primes. Just spread over more than one k. Is it like that?[/QUOTE]

Given: k * 2^n - 1

The risk you run with low-weights is that you do not find a prime at all,
because when the number of bits of the exponent n increases, the testing time goes exponentially up and there is going to be a limit that your hardware can quickly enough proces.

See a low weight as a big gamble.

Yet i'm also gambling upon one.

So currently actively i'm searching k=32767 (low weight) and k=89 (medium to heavy weight).

k=69 has been temporarily stopped, for a simple reason. My hardware has problems crunching above n=7Mbits - the L2 cache simply isn't large enough.

Nash-weight of course is a quick estimate.

Note that i'm also sieving k=32767 deeper and deeper. I'm now at a point that for quite a while sieving deeper is more useful than testing. With k=32767 that's roughly around n = 5Mbits for my hardware.

Note i started sieving until 30Mbits. So right now i'm sieving [5M ; 30M]

Probably that's becasue of wishful thinking from my side i ever will manage to get that far.

As i'm still removing quite a bit of exponents at larger sieve depths i would expect the odds for a prime is dramatically lower than one would expect for a different k with the same nash-weight where this sieving heuristic doesn't apply.

So if i'm so lucky i find 1 prime with k=32767 worth mentionning, yet odds is huge there isn't one. If the next k=32767 prime is located at 25Mbits then i'm not sure i'm gonna find it before having entirely white hair (and right now it's not yet grey) :)

For some small odds of finding 1 prime would you want to do all this effort and wait that many years?

On the other hand k=89 i need to do 20k tests between 4m and 5m - yet that'll take only a year or so. And 5m to 6m i do not know yet. Will depend upon whether i make enough cash to upgrade the hardware here :) Read - whether my 3d printer finally releases after that many years...

Yet odds are quite optimistic there is 1 or more primes between [4m and 8m].

The low weight is a total gamble and basically i probably am soon going to take the decision to just sieve [5m ; 30m] for a year to come. No nothing testing above 5M for now...

A single core from a magny cours processor here of 2.2Ghz removes on average 1 exponent each 3+ hours.

We can calculate the break even point when to start testing [5m;6m]
Well that's a 2:20 AM estimate here just typed in live.

BSGS algorithm works uses a square root trick you can find on wiki.
So we can see [5m ; 30m] versus [6m ; 30m] for sieving.

sqrt(24 mln) / sqrt (25mln) = 0.9797

So that's roughly 2%, So the sieving is 2% slower roughly if i keep testing the larger domain [5m;30m]

Now testing time at [4m;5m] is already 15000 seconds at 2 cores of a Xeon L5420 at 2.5Ghz. That's 8.3 hours for 1 core.

We assume an even distribution the sieving gets where it removes an exponent between [5m and 30m]

So when under this circumstance is there a break even point of testing expressed in removal rate?

A first attempt to calculate break-even point.... (yeah at 2:30 AM by now)...

Let's assume now that the average of [5m ; 6m] is 5.8M.

LLR time for 5.8M might be roughly 8.3 hours * (5.8M / 4.0M) ^ 2 = 17.5 hours

17.5 hours == removal_rate * 0.02 * (25M / 1M)

==> removalrate = (17.5 hours * 50 / 25) = 17.5 * 2 = 35 hours

So i might be sieving for years to come before i can start testing the low weight k=32767 :)


removal_rate

If you're willing to put in the work finding the FFT jumps (fun detective work IMO) and per-iteration times (not as fun; you may not want to run full tests the whole way like I did up to 512K), you can plug them into LLRTools ([url]https://www.mersenneforum.org/showpost.php?p=62302&postcount=35[/url]) and let that spit out the average test time for any range.

Happy - you sure you can't do better with a stick in the sand than that?

I could write a script to automate finding those FFT jumps? (It would help me immensely too.) Pick a language. I'm good at most common ones. :)

To be honest, I'm not sure who I was supposed to be answering. I thought I was coming up with a solution for your removal rate dilemma, if that hasn't already even been solved. My posts-per-page count (19) is such that I don't have the post you replied to on this page anymore.