Primes in π

[J F]

Update, still no luck with #20 up to 550K digits.
I will stop #20 for now, runtime >1h and chance
<1:1M per PRP-test is not too much fun. Some day
and with a notably faster machine I will probably
continue. Meanwhile only some parttime work on
some of the smaller unsolved ones.

[davar55]

Originally Posted by J F

Update, still no luck with #20 up to 550K digits.
I will stop #20 for now, runtime >1h and chance
<1:1M per PRP-test is not too much fun. Some day
and with a notably faster machine I will probably
continue. Meanwhile only some parttime work on
some of the smaller unsolved ones.

You call it no luck finding a prime.
I think the possibility that there may be no prime in this
particular sequence bears scrutiny. Actually proving that
may be as hard as proving any of the famous conjectures
about primes. So all your good work looking for one
is definitely of positive value.

[rogue]

It seems that the sieve I wrote for the Copeland-Erdos search might be effective in eliminating numbers from testing.

[rogue]

Here is a program you can use for sieving. The command line would look like this:

pixsieve -S20 -spi.txt -oterm.txt -iindex.txt -Rraw.txt -P1e7 -L100000 -m1e9

-s references a file with a single line that is all digits. In this case, pi. That line can be of any length.

-S is the starting string to search for in that string of digits, in this case "20". it is not required

-i is an output file of indexes. Eventually I will fix so that it can be correctly used as input to continue sieving.

-R is an output file of the raw terms that you can run thru pfgw for PRP testing.

-L is the maximum length of digits for sieving

-m is the minimum factor to output to the U/I. Note that output long strings consumes a lot of CPU, so it should be set high.

-f is an output file for factors, which can be verified with pfgw. It is not required.

This program can be used with any input string, so it could be used for Smarandache and Copeland-Erdos sieving as well.

Enjoy!

[ATH]

It looks great but maybe the screen output should not output the thousands or hundreds of thousands of digits in the strings for which the factors are found?

Maybe something like:

3198721 | 31415926535897932384...76020825202618798531 (6158 digits)

[rogue]

Originally Posted by ATH

It looks great but maybe the screen output should not output the thousands or hundreds of thousands of digits in the strings for which the factors are found?

Maybe something like:

3198721 | 31415926535897932384...76020825202618798531 (6158 digits)

I could do that. I would recommend using -m1e12 until I do something about that.

I was also thinking about an optimization. I don't know if I will have time to work on it today, but I think the program could be about 8x faster than what it is.

[rogue]

Originally Posted by rogue

I could do that. I would recommend using -m1e12 until I do something about that.

I was also thinking about an optimization. I don't know if I will have time to work on it today, but I think the program could be about 8x faster than what it is.

8x faster is not quite right. When starting from length 1, I can't do anything to increase the speed, when starting from a length > 1, i.e. 200,000 digits to 300,000 digits I can speed up the mulmod up to 200,000 digits by a factor of 8.

[J F]

Shiny! Rogue, thanks a lot for your effort. Just took it for a test drive, nice and fast!
Some questions:
1. Since Windoof can't handle command lines longer then some KB, I can't hand over
long --start_strings. Is there a way to set some offset so it doesn't sieve all
the way from start_string to --lmax, but from start_string+offset? a --lmin?
Or can it grab start_string from a file?
2. How do blocksize/chunksize/blocks translate into things like cache footprint,
thread overhead, bandwidth... - speed? I played around with it a bit, halving,
doubling... runtimes with a ~2min testcase varied <0.5%, explainable by
background load. Is pixsieve derived from some other sieve which may have
a .doc talking about that?
3. --help doesn't show the -o option from your example line, are there other hidden?

[rogue]

Originally Posted by J F

Shiny! Rogue, thanks a lot for your effort. Just took it for a test drive, nice and fast!
Some questions:
1. Since Windoof can't handle command lines longer then some KB, I can't hand over
long --start_strings. Is there a way to set some offset so it doesn't sieve all
the way from start_string to --lmax, but from start_string+offset? a --lmin?
Or can it grab start_string from a file?
2. How do blocksize/chunksize/blocks translate into things like cache footprint,
thread overhead, bandwidth... - speed? I played around with it a bit, halving,
doubling... runtimes with a ~2min testcase varied <0.5%, explainable by
background load. Is pixsieve derived from some other sieve which may have
a .doc talking about that?
3. --help doesn't show the -o option from your example line, are there other hidden?

1) Why do you need a long start string? As for an lmin parameter, I started making a change for that, but didn't complete it.
2) I'm not a guru on that. I don't recall where I got that code from, but I think it originated from fpsieve. I would be surprised if one could significantly change performance of the program (on a relatively current computer) by changing those values.
3) I probably missed it.

[J F]

Originally Posted by rogue

1) Why do you need a long start string?

Example: PrimesInPi, start value 20 has been tested up 550K digits. Sieving from
550K to 600K I translate to "--start_string=[a 550K number] --lmax=600K".
But Windows is laughing at me when I point it to a 1/2MB command line, mumbling
something about '8K ought to be enough for anybody.'
--Start_string=20 --lmax=600K would replicate work already done. And extending
later to 650K would replicate again. Thus the question about an offset or input
from file.

Or I'm missing something here?

[rogue]

Originally Posted by J F

Example: PrimesInPi, start value 20 has been tested up 550K digits. Sieving from
550K to 600K I translate to "--start_string=[a 550K number] --lmax=600K".
But Windows is laughing at me when I point it to a 1/2MB command line, mumbling
something about '8K ought to be enough for anybody.'
--Start_string=20 --lmax=600K would replicate work already done. And extending
later to 650K would replicate again. Thus the question about an offset or input
from file.

Or I'm missing something here?

Yes. What you want to do is -S20 because the numbers you are searching for start with "20". The problem is that it needs a -lmin parameter so that you can use -l550000 -L600000 so that it looks for 550000 to 600000 digit numbers starting with 20.

By adding -lmin I can speed up the calculation of the mod for the first number you are searching for.