A Sierpinski/Riesel-like problem

[Batalov]

Originally Posted by sweety439

(269*10^n+1)/9 seems to be tested to n=10000 (I ran the program of 25 hours and 38 minutes!!!), still no (probable) prime found, base released.

Mr Winston Wolf once said: "That's 30 minutes away. I'll be there in 10."

In comparison, it takes you 25 hours and 38 minutes to do a job that takes 10 minutes.
That doesn't bother you? Not at all?

[gd_barnes]

Originally Posted by Batalov

Mr Winston Wolf once said: "That's 30 minutes away. I'll be there in 10."

In comparison, it takes you 25 hours and 38 minutes to do a job that takes 10 minutes.
That doesn't bother you? Not at all?

Hey now! How ruuuuuuude! All of my machines are more than 4 years old. I ran a 5+ year old version of PFGW (version 3.3.6) with no sieving (trial-factoring only) on my newest 4-year-old machine with 5 other cores running at the same time and it took 18 minutes.

So now I'm sad that you make fun of my old machines and software that take almost twice as long as you say it should. (lol)

Anyway...a modern machine running a modern version of PFGW with some sieving done should likely take ~5 minutes.

I don't think anything bothers Sweety. We can insult him all day long and he just keeps posting trivial results.

[Batalov]

Originally Posted by gd_barnes

I ran a 5+ year old version of PFGW (version 3.3.6) with no sieving (trial-factoring only)

Well for these PRPs with a denominator one should run only LLR or P95. They are a few times faster. And there are <300 tests for n<10,000 and each is much faster than a second, ...so 10 minutes was said only to match the Wolf quote.

Originally Posted by Mr.Wolf

I'm Winston Wolf. I solve problems.

[gd_barnes]

Originally Posted by Batalov

Well for these PRPs with a denominator one should run only LLR or P95. They are a few times faster. And there are <300 tests for n<10,000 and each is much faster than a second, ...so 10 minutes was said only to match the Wolf quote.

Hum....How might one run LLR with a denominator? I've never tried it before and just now tried this:

ABC ($a*10^$b$c)/9 // Sieved to 1000000000 with srsieve
269 47 +1
269 51 +1
269 84 +1
269 96 +1
269 105 +1
(etc.)

LLR would not run. It runs fine without the denominator. I'm running LLR 3.8.13...not the latest version but it should be recent enough.

[Batalov]

ABC ($a*$b^$c$d)/$e
269 10 47 +1 9
...

You will be very pleasantly surprised. Essentially the speed is the same as if without $e.

[gd_barnes]

Originally Posted by Batalov

ABC ($a*$b^$c$d)/$e
269 10 47 +1 9
...

You will be very pleasantly surprised. Essentially the speed is the same as if without $e.

Thanks! Not bad. About 8 mins on that same old machine with 5 other cores running, which includes about 1 minute to over-sieve to 1G. If done efficiently on a modern machine...likely 3 mins.

[LaurV]

Originally Posted by gd_barnes

ABC ($a*10^$b$c)/9 // Sieved to 1000000000 with srsieve
269 47 +1
269 51 +1
269 84 +1
269 96 +1
269 105 +1
(etc.)

What version of srsieve can do that sieving?

[axn]

Originally Posted by LaurV

What version of srsieve can do that sieving?

Are you worried about the denominator 9? Just skip 3, and srsieve will take care of correctly sieving the numerator k*b^n+/-c

[gd_barnes]

Originally Posted by LaurV

What version of srsieve can do that sieving?

Originally Posted by axn

Are you worried about the denominator 9? Just skip 3, and srsieve will take care of correctly sieving the numerator k*b^n+/-c

Just to clarify:

I did not actually sieve ($a*10^$b$c)/9. I sieved $a*10^$b$c accomplishing exactly what axn said with -p 4 -P 1e9. After the sieving was done I then added the parens and denominator. Btw, this was a technique that I learned from Serge less than a week ago...one that I was not aware of because I've never searched repeat-digit type forms.

A note about this: In this case the sieving still leaves terms with factors of 3^q after dividing by 9. When running PFGW I get around this by trial factoring to 1% with the -f1 switch so it doesn't do a full primality test. It generally takes less than 1/10th of a second to trial factor to 1%.

This begs a question: Does LLR look for teeny factors before doing a primality test? I could not tell with the short test that I ran on it here. If not I may stick with PFGW because it can quickly get rid of very small factors that are left when sieving a form with a denominator like this.

[LaurV]

Yes, I did exactly the same in the other thread of sweety, I just created a folder (called bp and copied his bases there, in a vector), filled it with sr_bxxx.pfgw files using pari:

gp> \r bp\bases
gp > (16:13:53) gp > v
%1 = [184, 185, 200, 210, 269, 281, 306, 311, 326, 331, 371, 380, 384, 385, 394, 396, 452, 465, 485, 511, 522, 570, 574, 598, 601, 629, 631, 632, 636, 640, 649, 670, 684, 691, 693, 711, 713, 731, 752, 759, 771, 795, 820, 861, 866, 872, 881, 932, 938, 948, 951, 956, 963, 996, 1005, 1015]
gp > for(i=1,#v,write("BP\\nrep_b"v[i]".pfgw","ABC $a*"v[i]"^$b$c // Sieved to "nextprime(v[i])" with srsieve");forprime(p=3,10^4,write("BP\\nrep_b"v[i]".pfgw","1 "p" -1")))
time = 1min, 4,259 ms.

This just took a minute and the result was: (random sample)

ABC $a*636^$b$c // Sieved to 641 with srsieve
1 3 -1
1 5 -1
1 7 -1
1 11 -1
1 13 -1
1 17 -1
1 19 -1
1 23 -1
...etc...

This can be sieved with primes larger than 641 (inclusive) and a simple dos for command solves the problem:

for %p in (nrep_b*.pfgw) do srsieve -S 2 -m 1e8 -w "%p"

In minutes, all the files with even base are reduced to less then half candidates, and files like "sr_bxxx.pfgw" are created from "nrep_bxxx.fgw". For the odd bases, srsieve gives an error that all terms are even, which I don't know how to avoid.

Then a perl command will replace all headers:

for %p in (sr_*.pfgw) do perl -i.bak  -p -e "s/ABC \$a\*(\d*)\^\$b\$c/ABC (\$a*\1^\$b\$c)\/(\1-1)/g;" %p

(this is heavy artillery, hehe)

And of course, you will want pfgw to stop when a prime is found, therefore

for %p in (*.pfgw) do perl -i.bak  -p -e "s/Sieved to \d* with srsieve/{number_primes,\$a,1}/g;" %p

Result:

ABC ($a*210^$b$c)/(210-1) // {number_primes,$a,1}
1 7 -1
1 11 -1
1 17 -1
1 31 -1
1 103 -1
1 107 -1
1 157 -1
1 173 -1
1 227 -1
1 257 -1
1 269 -1
1 331 -1
1 347 -1
1 353 -1
1 383 -1
1 397 -1
...etc...

This feed to pfgw with another dos for command for all files. I know my tools, trust me, I was just wondering if there is a newer version of srsieve. Especially because the version which is marketed like 1.0.6 on the web, shows 1.0.5 when is executed (I downloaded from many places, and yes, all are the same). So I was more like wondering if there is another, real version 1.0.6

Thanks anyhow...

[gd_barnes]

Originally Posted by LaurV

For the odd bases, srsieve gives an error that all terms are even, which I don't know how to avoid.

There is no way around it except for forms that are c=-1 or +1 and even the solution for those is not ideal. The program would have to be changed to avoid checking for the error. Both srsieve and sr2sieve have the same problem.

For c=-1 or +1 forms, you can use sr1sieve but it will only sieve where the factors are greater than the base so you'd have to figure a way to remove smaller factors or just do like I did and run PFGW with factoring set to 1% with -f1. Also if you are sieving multiple k's at once, which I am frequently doing on some of these conjectures, you have to sieve them one k at a time...not a great solution.

Would someone want to get ahold of Mark (rogue) and see if he can remove the error check from srsieve and sr2sieve where it says all terms are even? That becomes a major issue when sieving near repeat digit forms for odd bases.