Another sieving gap in Psieve files

[Batalov]

Originally Posted by Thomas11

k=41 tested to n=3M, prime for n=2872058. Releasing this k.

I reserve k=41 from n=3M to 4M.

Here's an interesting thing. Even though RSP sieve files are extremely well sieved, there's a strange gaping hole of unremoved factors from ~35T to 40T (I know that because I ran the sieve for a while to warm up). That is quite a lot of factors (and very easily removed -- compared to e.g. sieving from 368P to 400P). What happened there?

@RSPsieve folks: You may want to check. This is likely not specific to just k=41, -- rather the whole range of 5<k<10^4.

[pinhodecarlos]

Dear Batalov,

The files are sieved by PrimeGrid so I think it is better to post your doubt in this forum:

http://primesearchteam.com/showthread.php?t=62

Thank you,

Carlos

Edit: Track down of the sieve in here: http://primesearchteam.com/showthread.php?t=67

[Batalov]

Dude, it is not a doubt. It is a fact.

I know those forums. I'll send a PM to jimB and to Michael G.

I just thought that because there's a lot of local users here - they should know.

In the meantime, I've run some additional tests. The gap is not specfic to this k, and is not specific to the rsp4M file; rsp5M file has the same hole.

[pinhodecarlos]

Originally Posted by Batalov

Dude, it is not a doubt. It is a fact.

Ok dude. Post there your fact.

[Batalov]

Originally Posted by pinhodecarlos

Ok dude. Post there your fact.

Well, is you ask so nicely.

Someone (oh wait! it was you) recently spent a couple CPUdays to prove that these numbers are not prime, right?

5*2^3833000-1 is not prime.  LLR Res64: EF6538EB4B780F59  Time : 5192.823 sec.
5*2^3835702-1 is not prime.  LLR Res64: 0728DEF213A250DF  Time : 5031.540 sec.
5*2^4015434-1 is not prime.  LLR Res64: 081EDC84F2E92E8A  Time : 15320.036 sec.
5*2^4016160-1 is not prime.  LLR Res64: 265756DD603BFA87  Time : 14669.182 sec.
5*2^4017630-1 is not prime.  LLR Res64: EA094FD13C875290  Time : 14589.806 sec.
5*2^4028734-1 is not prime.  LLR Res64: 23238AB6DE3C88D5  Time : 14830.640 sec.
5*2^4028974-1 is not prime.  LLR Res64: 869FFDB9A44CE514  Time : 14819.700 sec.
5*2^4070850-1 is not prime.  LLR Res64: B7EE5C708F0D496F  Time : 16839.752 sec.
5*2^4072010-1 is not prime.  LLR Res64: 6BA9E053CC6F0E44  Time : 14937.687 sec.
5*2^4073652-1 is not prime.  LLR Res64: FE039F55CA5CB9C5  Time : 14899.431 sec.
5*2^4083350-1 is not prime.  LLR Res64: 4AA3CBF70090C8AB  Time : 14924.623 sec.
5*2^4106488-1 is not prime.  LLR Res64: 94B207C92E7157C8  Time : 5311.460 sec.
5*2^4090802-1 is not prime.  LLR Res64: 50EA85A11D58DA06  Time : 5147.836 sec.
5*2^5001882-1 is not prime.  LLR Res64: E5BC8122A7B468BA  Time : 9051.502 sec.

Here's a shorter proof:

39029422217881 | 5*2^3833000-1
39032382281219 | 5*2^3835702-1
38914522784999 | 5*2^4015434-1
38455014358121 | 5*2^4016160-1
37316717136131 | 5*2^4017630-1
35297808689399 | 5*2^4028734-1
38668821972629 | 5*2^4028974-1
38238241741211 | 5*2^4070850-1
35844095246621 | 5*2^4072010-1
39913015974101 | 5*2^4073652-1
35471132068399 | 5*2^4083350-1
35804963741159 | 5*2^4090802-1
39538077919441 | 5*2^4106488-1
36040768901629 | 5*2^5001882-1

Nope. Not prime. Have small factors. Takes a microsecond to verify.

Convinced now?

[pinhodecarlos]

Batalov, I am asking you to post on that forum. I believe you.

[Kosmaj]

Hi Batalov,

Thanks for pointing that out! We discovered about 18 months ago a gap in sieving k=5 in the p=1-400 bn (E9) range. That time only k=5 was affected, for n>3M. Later, JimB found a few more missing ranges for n>5M, but again only for k=5 (see #35 in that thread).

Apparently this is a new issue, but this time it appears that all k<10000, n>3M are affected (?)

[pinhodecarlos]

There are no gaps from sieving 4 < k < 10000 for 3M < n < 4M starting at 0G to 650000G (source http://primesearchteam.com/showthread.php?t=67). I think after 650000G the sieve effort went through BOINC platform.

I just don't understand when the CPU client was used and when the GPU client was used. I suppose until 5000G the CPU client was used and beyond that the GPU client was used but I am not sure. JimB may answer this.

Or the client is missing factors or someone forgot to eliminate the factors.
Better a factor miss than a prime eliminated.

[unconnected]

For k=29 there are also missed factors.

sr1sieve 1.4.5 started: 4000168 <= n <= 4999936, 35000000000000 <= p <= 40000000000000
35228403602813 | 29*2^4539184-1
35231070097339 | 29*2^4034980-1
35281414864651 | 29*2^4578820-1
35497506560591 | 29*2^4067224-1
35513458372199 | 29*2^4319872-1
35518310359871 | 29*2^4258024-1
...

[Batalov]

JimB is aware of the problem now (via PM) and he wrote that:
- tpsieve finds the factors, too (not just sr[12]sieve)
- there could be different logistic reasons for why this happened (that's a separate, not important for us, issue)
- he could requeue this (very small by modern standards) range back on BOINC, but this would need waiting for the tasks that are already in queue, then waiting for all jobs to finish etc...
- therefore, he will simply run the range himself (or with some other admin's help) and it will take only a few days on a couple GPUs.

Bottom line: this will be fixed in a matter of a week.

However, if you have time, everyone could run sr1sieve on your particular k (I know I did - and more or less by accident)
or
just refresh your k files after the patch, in a week.
This is only ~1/200 unnecessary tests we are talking about here.

[pinhodecarlos]

Thank you Batalov for the update. Meanwhile PrimeGrid is now sieving again from 0P to 1P all k's, + and - side. Check here: http://www.primegrid.com/stats_pps_sieve.php