Sierp base 3 reservations/statuses/primes

[KEP]

@Gary, well as mentioned in my e-mail to you, or at least I hope this will leave you in no doubt:

The one sieve file for Base 27 with more candidates remaining is simply because of higher sieve ranges, hence less candidates removed, but in fact range 1 and 2 started out being the same size (if I remember it right)!

KEP!

[gd_barnes]

Sierp base 3 is now complete to k=25M and n=25K. For k=15M-25M, 47 additional k's were found to be remaining and are now shown on the web pages.

In additional to the 55 k's remaining for k=1-15M, this now makes 102 k's remaining for k<25M to n=25K. Including the ranges completed by Micha and Kenneth, we are now at 228 total k's remaining for the ranges of k<25M and k=100M-120M.

I'm continuing on to k=30M as per my reduced reservation.

If anyone wants to do k=30M-50M to n=25K for Sierp base 3, that would be a good range to work on now. If there is no interest, I'll take on the effort starting within a couple of months.

IMHO, we should do a sieve for n=25K-200K for all k's remaining once we reach k=50M. There should be ~200-250 k's in such a sieve.

Continuing to find 1000's of small primes gets quite boring after a while and it will make the effort more interesting if we do that in conjunction with sieving and searching for some larger primes.


Gary

[michaf]

Originally Posted by gd_barnes

If anyone wants to do k=30M-50M to n=25K for Sierp base 3, that would be a good range to work on now. If there is no interest, I'll take on the effort starting within a couple of months.
Gary

I'll take this one. I'll set my script to work upto 25k at once, so I'll use no sieve at all, just trial factoring in pfgw.

(If I get away from the comp, it might run a bit further then 50M, but that will be ok I guess :) )

If about 200-300 k's are left at 50M, let's make that the standard 'running length'.
After sieving those, we'll need to get an 'optimum standard sieve depth' for those chunks.

I'll take a mental note that I started this as 0:35 24-05-08 :>

One advantage of the script is, that I can tell you exactly which ones remain upto the range tested so far... (none upto 30025000)...

First one found at: 30032708 1:19 24-05-08
(it was the first one to run over 10k too...)

[michaf]

Originally Posted by gd_barnes

Continuing to find 1000's of small primes gets quite boring after a while and it will make the effort more interesting if we do that in conjunction with sieving and searching for some larger primes.

Gary

I thought we were looking for 'non-primes' now

[gd_barnes]

Originally Posted by michaf

I'll take this one. I'll set my script to work upto 25k at once, so I'll use no sieve at all, just trial factoring in pfgw.

(If I get away from the comp, it might run a bit further then 50M, but that will be ok I guess :) )

If about 200-300 k's are left at 50M, let's make that the standard 'running length'.
After sieving those, we'll need to get an 'optimum standard sieve depth' for those chunks.

I'll take a mental note that I started this as 0:35 24-05-08 :>

One advantage of the script is, that I can tell you exactly which ones remain upto the range tested so far... (none upto 30025000)...

First one found at: 30032708 1:19 24-05-08
(it was the first one to run over 10k too...)

OK, good. I'll mark you down for k=30M-50M on the Sierp side. When you find one remaining that is divisible by 3, see if it can be reduced to a k-value that is already remaining --OR-- (an important 'or') if it reduces to a k-value that has a prime that is n>25K as shown in the top-10 primes on my web page. (Many were found from the top-5000 site and I searched several others to n=50K and one other to n=100K because I didn't want to break my ZERO k's remaining streak for a long time. lol) If your k-value hits either condition, then you can eliminate it.

I'll start again on Sierp base 3 k=25M-30M after the NPLB rally late Sunday. ETA is 5-6 days on 2 slower-speed cores.

I agree on the sieving. In the future, we'll sieve all k-values remaining for each k=50M range...should be 200-300 of them. I was suggesting the n=25K-200K range but we can determine that more specifically when we get close to completing up to k=50M.


Gary

[michaf]

Status on Sierpinski base 3, 30-50M:
finished sieving (upto 5G seems about right, removal rate was just about 8-10 sec/n, and llr takes 7.something seconds to test.

Sr2sieve wasn't used, it gave malloc error :(
remaining at n=10k: 289 k's

[KEP]

Originally Posted by michaf

Status on Sierpinski base 3, 30-50M:
finished sieving (upto 5G seems about right, removal rate was just about 8-10 sec/n, and llr takes 7.something seconds to test.

Sr2sieve wasn't used, it gave malloc error :(
remaining at n=10k: 289 k's

Well for 289 k's sr2sieve should be able to help you out. Also if you read my other post in the base3/7/15 thread, you will se that testing 50,000 k's from n1 to 25,000 will require about 315 MB of RAM using srsieve, while testing ~1,500 candidates using sr2sieve will require ~700 MB of RAM (give and take)!

Hope all is well, just out of curiosity, do you use -t, to make sure that infact primes is found using your script hence avoiding a lot of double checking later on?

KEP!

[michaf]

Originally Posted by KEP

Well for 289 k's sr2sieve should be able to help you out. Also if you read my other post in the base3/7/15 thread, you will se that testing 50,000 k's from n1 to 25,000 will require about 315 MB of RAM using srsieve, while testing ~1,500 candidates using sr2sieve will require ~700 MB of RAM (give and take)!

Hope all is well, just out of curiosity, do you use -t, to make sure that infact primes is found using your script hence avoiding a lot of double checking later on?

KEP!

Sr2sieve started to make the legendre tables, and quitted at about 60% done. Is there a way to NOT make the tables?

And no, I haven't used -t as starters, but will check all the primes later on indeed.

[gd_barnes]

Originally Posted by michaf

Sr2sieve started to make the legendre tables, and quitted at about 60% done. Is there a way to NOT make the tables?

And no, I haven't used -t as starters, but will check all the primes later on indeed.

Actually, I doubt that it quit. It just encountered one that takes it many minutes or an hour or more. When I was doing a 12-k test for base 2 at RPS where 100K < k < 35M, there was one k that it to 3 hours to do the Legendre tables for. I tried it 3 times and on the 3rd time, I just let it sit there because I refused to believe that it just 'locked up' and it finally calculated all of them.

Just let it crunch overnight on the tables if you have to.

Be sure and save off the Legendre tables for the k's you're testing. That way you won't have to do it again if you start and stop the sieve or run it on more than one machine. I don't know if there's a way to make it NOT create the tables.

Alternatively you can just use srsieve, albeit at a much slower sieving speed. Another alternative is to remove the 'problem' k and sieve it separately using sr1sieve.

When doing the sieving using sr2sieve for n>25K for 200+ k's for all k<50M, we'll just have to wait and let it create the tables if the machine has enough RAM.


Gary

[michaf]

Originally Posted by gd_barnes

Actually, I doubt that it quit. It just encountered one that takes it many minutes or an hour or more. When I was doing a 12-k test for base 2 at RPS where 100K < k < 35M, there was one k that it to 3 hours to do the Legendre tables for. I tried it 3 times and on the 3rd time, I just let it sit there because I refused to believe that it just 'locked up' and it finally calculated all of them.

Just let it crunch overnight on the tables if you have to.

I'm patient enough :)
It quitted with a malloc error unfortunately :(

Be sure and save off the Legendre tables for the k's you're testing. That way you won't have to do it again if you start and stop the sieve or run it on more than one machine. I don't know if there's a way to make it NOT create the tables.

Alternatively you can just use srsieve, albeit at a much slower sieving speed. Another alternative is to remove the 'problem' k and sieve it separately using sr1sieve.

Yep, that's just what I did, it didn't take too long to sieve to 5G, iirc, it was done overnight.

When doing the sieving using sr2sieve for n>25K for 200+ k's for all k<50M, we'll just have to wait and let it create the tables if the machine has enough RAM.

Gary

We'll see what it gives, unexpected things happen all the time here

[gd_barnes]

Originally Posted by michaf

I'm patient enough :)
It quit with a malloc error unfortunately :(

Oh yeah, you said that either. Either your machine doesn't have enough memory or sr2sieve isn't able to allocate enough memory for the table in question, most likely the latter.