Testing new Ranges for Sierpinski/Riesel

[rogue]

Thanks to KEP I found a bug in the trivial factoring code of pfgw that impacts usage of the new-base script. He discovered that pl_MOB.txt was different between two runs. I've asked him to test a fixed version of pfgw. This only affects pfgw 3.5 and later.

What this means is that there might be k in pl_remain.txt that could have been removed by the MOB test. Those k are most likely in pl_prime.txt for a small n, but not necessarily.

[pepi37]

Hi Rogue
I play with your tool and still find some errors. Maybe it is what you told about PFGW, but I think it is not

I know that you say that first must be created npg file, but that step I jump because I dont understand how to create it. So if "this" error is because of that I greatly excuse.

So this is my ini file

base=10
mink=1
maxk=20000
c=1
phase=80,50000,500000
phase=300,30000,3000000
phase=1000,20000,10000000
phase=3000,10000,30000000
phase=5000,50000,100000000
phase=10000,100000,500000000
phase=50000,500000,1500000000
phase=150000,250000,3500000000
phase=250000,350000,4500000000
phase=350000,450000,5500000000
phase=550000,750000,8500000000

after run about half of hour I got this in sieve ( part of log)

07/25/15 02:54:14 srsieve started: 10001 <= n <= 50000, 3 <= p <= 1500000000
07/25/15 02:54:14 removed candidate sequence 9175*10^n+1 from the sieve -conjectured K
07/25/15 02:54:14 removed candidate sequence 9351*10^n+1 from the sieve
07/25/15 02:54:14 removed candidate sequence 17676*10^n+1 from the sieve
07/25/15 03:01:49 srsieve stopped: at p=1500000000 because --pmax was reached.

Regardless of that in pl_remain all three candidates are here ( pl remain)

4069*10^n+1
5028*10^n+1
6172*10^n+1
7404*10^n+1
7666*10^n+1
7809*10^n+1
8194*10^n+1
9175*10^n+1 <-----
9351*10^n+1 <-----
10209*10^n+1
11353*10^n+1
11703*10^n+1
14772*10^n+1
15357*10^n+1
16587*10^n+1
17676*10^n+1 <-----
18888*10^n+1
19218*10^n+1
19614*10^n+1

[rogue]

That is quite ok. srsieve does that because all n in the range you are sieving for those k have been removed by sieving. That happens fairly often for small ranges of n.

[pepi37]

But why then those three candidates are tested anyway?
Should they be removed from testing at start?

[Batalov]

Originally Posted by pepi37

But why then those three candidates are tested anyway?
Should they be removed from testing at start?

Why are you testing above conjectured K, anyway?
You should have set

maxk=9174

because CK=9175 is well known. Set maxk to CK-1.

You can test it outside of this script, only to convince yourself

> srsieve -g -n 1 -N 250000 -P 400000 "9175*10^n+1"
srsieve 1.0.6 -- A sieve for integer sequences in n of the form k*b^n+c.
srsieve started: 1 <= n <= 250000, 3 <= p <= 400000
removed candidate sequence 9175*10^n+1 from the sieve
Sieving 3 <= p <= 41 eliminated 250000 terms, 0 remain.
srsieve stopped: at p=41 because all candidate sequences were eliminated.

Whatever happens for k>= CK is not a bug and Mark should not fix it.
This thread is about srbsieve, and "removed candidate sequence 9175*10^n+1 from the sieve" is reported by an internal call to srsieve (which of course doesn't have any notion about external files and will not remove anything from them; it only informs you, the operator, that it fully eliminated some internal 'candidate sequences').

Now, it is possible to misinterpret what srsieve says, as well (and Mark already said about that: if the interval is small, where small is a subjective word). Suppose we run a very small interval of n (just 25000 and 25001)

> srs -g -n 25000 -N 25001 -P 400000 "7666*10^n+1"
srsieve 1.0.6 -- A sieve for integer sequences in n of the form k*b^n+c.
srsieve started: 25000 <= n <= 25001, 3 <= p <= 400000
removed candidate sequence 7666*10^n+1 from the sieve
Sieving 3 <= p <= 23 eliminated 2 terms, 0 remain.
srsieve stopped: at p=23 because all candidate sequences were eliminated.

This message does not mean that you can "remove this sequence from file". And if you cannot remove a sequence in one case, the you cannot remove it in general case, so these internal messages should be ignored.

So, simply remember that there are sequences and then there are sequences - and they are not the same. (Cf. Ecclesiastes)
The CK determination is a special skill and is beyond this particular discussion. Suffices it to say that it is already determined and tabulated for you by Gary (and Robert Smith, and others) and is given to you by CRUS webpage. It is 9175 for S10.

Yet another question is why would you run tests on S10. It is well worked on. You want a new sequence? Take R201 with CK of 3669230 and srbsieve it to 0.1M for starters. Or S301 for the full range to CK-1: 1 to 1061981. That would be a (sort of) meaningful work. But it won't be easy. (and is already done, too) There is something else meaningless that occurs on earth: the righteous who get what the wicked deserve, and the wicked who get what the righteous deserve. This too, I say, is meaningless. (Eccl.8:14)

[pepi37]

Originally Posted by Batalov

Why are you testing above conjectured K, anyway?

And why not? Did I do any harm doing that: dont just tell me there is no primes in sequences above conjectured k?
Lets say I just wont ( need, have a fun) find prime that is in range of those conditions:
base 10, k from 1 to 20000, and n above 25000 , so that k doesnot have prime before 25k.
Rogue tool is perfect for this kind of job. It save many hours of work, many many hours.

And now part with sieve
There is small app called nash ,and that tool say weight of k in specific base.
But guess what in all three cases nash weight is 0.
So that is proof I dont need to spend any second more on those sequences, right?
So if I dont need to spend any second more, why will I test them?
There is no reason, and you do know that.

Also your proof was pretty silly.

You give me example of two sequences, one with all candidates removed ,and one that also remove all candidates because very small range. That is no same: when you mix apples and pears , you will only get juice.

If I set wider range and I do that ( so I doesnot sieving range between two n) I got this

srsieve --newpgen --nmin 1 --nmax 1000000 --pmax 100000000 "7666*10^n+1"
for results I got
Sieving 3 <= p <= 100000000 eliminated 990664 terms, 9336 remain.
Wrote 9336 terms for sequence 7666*10^n+1 to NewPGen format file `t16_b10_k7666.npg'.

and that corespondent with nash weight of that sequence 7666 10 263 261
but I can make range big as universe in case of 9175*10n+1 and still results will be same .
Proof : it is conjectured K so there is no prime in sequence...
So tell me again: why to test sequence that is KNOWN to not have any prime
Maybe you can prove or disprove that , but I will not.
Nash weight is 0, so in that sequence there is no primes to search.
Period.
My knowledge of mathematics is far, far, far^n+1 bellow your, but for this it is not needed to be genius...
But how am I?
Small guy with just a little different view of yours. And with little different use of tool that Rogue give to us.
No hard filings.
Best regards

[rogue]

FYI, I will be on vacation for the next 16 days. I might get on the forum now and then, but most likely won't have time to post anything or fix anything. As I've posted the source of srbsieve, if any bugs occur, someone else might be able to fix them. KEP is testing the fixed version of pfgw. If that passes, I will update sourceforge. Hopefully sourceforge has fixed its problems by then as I have been unable to access the repository for a week.

[pepi37]

Rogue, relax and forget about computer world :)
Stay well

[Batalov]

I can play your game!
Let me ask you: "Why is the sun blue?"
You will probably tell me: "That's just nonsense. It is not blue - it is yellow."
If you'd want to show deep knowledge you will add: "And when occasionally it appears black, that's an eclipse. It is still yellow behind the moon that occludes it. It is still not blue."

Now:

Originally Posted by pepi37

So if I dont need to spend any second more, why will I test them?
There is no reason, and you do know that.

Errh... That's nonsense with all due respect to the small guy with just a little different view.
It is not being tested, and not even a millisecond is spent on it. Some nanoseconds maybe.
The only reason that it even appears (to you) to be tested is that you left it in the file by deliberately bending the rules (using the tool for what is not designed).

[paulunderwood]

“The sun’s not yellow it’s chicken”

[rebirther]

Is there a documentation / guide how to use srbsieve?