Primes in π - Page 16

ATH · 2016-06-03, 13:53

31415926535897932384...89830932080370010789 is Lucas PRP! (70233.3140s+30.6992s)
(613373 digits)

CRGreathouse · 2016-06-03, 15:22

Quote:

Originally Posted by ATH

31415926535897932384...89830932080370010789 is Lucas PRP! (70233.3140s+30.6992s)
(613373 digits)

Nice find! Have all the smaller ones been cleared?

ATH · 2016-06-03, 17:39

It is not my find, I was just adding a Lucas test on it. See post #143-#146.

Though I have been working on PiPrimes. I got up to around 350k digits, but I guess I was too late

rogue · 2016-06-03, 20:53

I have posted pixsieve 2.1 here.

It will now output files in the DECIMAL format which is supported by pfgw 3.8.1. That makes for much smaller files and a lot less I/O. The ability to continue from a previously sieved file now works, so you can start a sieve with pixsieve -P1e8 -l20000 -L30000 -C20000 -oterms.out -spi.txt -t4 -S15 then continue with pixsieve -P1e9 -iterms.out -oterms.pfgw -t4. The last prime in the range is written to the terms file so restarting will not require you to specify -p. Also the -F option has changed. Like the terms file (-o) this will expect a file name. That file will also be written in the DECIMAL format so that pfgw can verify factors. The only caveat with -F is that it will always overwrite any pre-existing file, so be careful with that if you want to verify factors.

J F · 2016-06-04, 20:59

Doing some tests, looks fine so far.
Cosmetics: v2.1 calls itself 2.0
Has 2.1 an option so switch between old format and new DECIMAL output?
Is 2.0=2.1 except the output format and resume? (than that would be the 'switch')

Edit: didn't need resume for now, jobs small enough or ProcessExplorers suspend/resume,
but I just noticed it seems to use wall clock, not compute time, and S/R or SuspendToDisk
totally garbles secs/factor. Hm...

Edit2: continuing with -i form previous file garbles too
Sieve started: (input file) 66068881 <= p < 100000000 with 913 terms
...12 factors found at 122089583 secs/factor...
It does get back on track to some degree, but it seems at 'deeper' runs with new factors
trickling in only very slowly, not so much.

rogue · 2016-06-05, 00:25

Quote:

Originally Posted by J F

Doing some tests, looks fine so far.
Cosmetics: v2.1 calls itself 2.0
Has 2.1 an option so switch between old format and new DECIMAL output?
Is 2.0=2.1 except the output format and resume? (than that would be the 'switch')

Edit: didn't need resume for now, jobs small enough or ProcessExplorers suspend/resume,
but I just noticed it seems to use wall clock, not compute time, and S/R or SuspendToDisk
totally garbles secs/factor. Hm...

Edit2: continuing with -i form previous file garbles too
Sieve started: (input file) 66068881 <= p < 100000000 with 913 terms
...12 factors found at 122089583 secs/factor...
It does get back on track to some degree, but it seems at 'deeper' runs with new factors
trickling in only very slowly, not so much.

The main difference is the format, but I mentioned all of the other changes in the release. There is no way to switch formats. If would be very easy for someone to write a script that does the conversion so I will leave that to someone who might be desperate for it.

Yes, factor removal rate is based upon wall clock. I will not change that. All other sieves that I have used or coded (and that is a lot of different programs) are based upon the wall clock. Even PRP testing programs tend to use the wall clock.

As for continuing, the code must not be initializing something correctly or the calculation is flat out wrong.

J F · 2016-06-05, 08:59

Hmmm, couldn't you store the old runtime, secs/factor and %done in the
DECIMAL file too, like the '// Sieved to...', and init a resume from that?
(Under the assumtion that PFGW ignores the //-part and wouldn't need
additional changes too.)

Edit: scratch %done - not good since one can resume with a different -pmax

J F · 2016-06-11, 12:46

(Minor?) Bug with new PFGW 3.8.1, DECIMAL format. Resuming an
interupted run (file from a 10K sieved range with a bit less than 300
numbers, 280-290K digits) outputs:
Invalid format on line 1
and then some 100 lines with

Code:

Length is beyond length of decimal on line 1Length is beyond lengt
h of decimal on line 1Length is beyond length of decimal on line 1Length is beyond length
of decimal on line 1Length is beyond length of decimal on line 1Length is beyond length of

Aside from that spam, it picks up at the correct point and seems to continue
without further problems.

Edit: No, it doesn't always continue, sometimes it just stops with 'Invalid format on line 1'
When I have time, I will test some more.

rogue · 2016-06-11, 13:58

Quote:

Originally Posted by J F

(Minor?) Bug with new PFGW 3.8.1, DECIMAL format. Resuming an
interupted run (file from a 10K sieved range with a bit less than 300
numbers, 280-290K digits) outputs:
Invalid format on line 1
and then some 100 lines with

Code:

Length is beyond length of decimal on line 1Length is beyond lengt
h of decimal on line 1Length is beyond length of decimal on line 1Length is beyond length
of decimal on line 1Length is beyond length of decimal on line 1Length is beyond length of

Aside from that spam, it picks up at the correct point and seems to continue
without further problems.

Edit: No, it doesn't always continue, sometimes it just stops with 'Invalid format on line 1'
When I have time, I will test some more.

I'll take a look when I have some time.

rogue · 2016-06-13, 16:20

Quote:

Originally Posted by rogue

The main difference is the format, but I mentioned all of the other changes in the release. There is no way to switch formats. If would be very easy for someone to write a script that does the conversion so I will leave that to someone who might be desperate for it.

Yes, factor removal rate is based upon wall clock. I will not change that. All other sieves that I have used or coded (and that is a lot of different programs) are based upon the wall clock. Even PRP testing programs tend to use the wall clock.

As for continuing, the code must not be initializing something correctly or the calculation is flat out wrong.

I updated to 2.2. This fixes the factor rate showing wildly inaccurate numbers.

rogue · 2016-07-06, 16:01

Quote:

Originally Posted by rogue

I'll take a look when I have some time.

I have a fix for this that I am still testing. The problem is caused by the underlying restart logic in pfgw which, to put it mildly, is a piece of crap. It was designed to figure out which line of the input file to restart from, but is really fairly specific to ABCD formats. It does a lot of weird stuff to try to find the correct line. It obviously works for most file types, but that is only because the code is a complete hack.

2016-06-04, 20:59	#170
J F Sep 2013 2³×7 Posts	Doing some tests, looks fine so far. Cosmetics: v2.1 calls itself 2.0 Has 2.1 an option so switch between old format and new DECIMAL output? Is 2.0=2.1 except the output format and resume? (than that would be the 'switch') Edit: didn't need resume for now, jobs small enough or ProcessExplorers suspend/resume, but I just noticed it seems to use wall clock, not compute time, and S/R or SuspendToDisk totally garbles secs/factor. Hm... Edit2: continuing with -i form previous file garbles too Sieve started: (input file) 66068881 <= p < 100000000 with 913 terms ...12 factors found at 122089583 secs/factor... It does get back on track to some degree, but it seems at 'deeper' runs with new factors trickling in only very slowly, not so much. Last fiddled with by J F on 2016-06-04 at 21:36

2016-06-05, 08:59	#172
J F Sep 2013 2³×7 Posts	Hmmm, couldn't you store the old runtime, secs/factor and %done in the DECIMAL file too, like the '// Sieved to...', and init a resume from that? (Under the assumtion that PFGW ignores the //-part and wouldn't need additional changes too.) Edit: scratch %done - not good since one can resume with a different -pmax Last fiddled with by J F on 2016-06-05 at 09:06

2016-06-11, 12:46	#173
J F Sep 2013 70₈ Posts	(Minor?) Bug with new PFGW 3.8.1, DECIMAL format. Resuming an interupted run (file from a 10K sieved range with a bit less than 300 numbers, 280-290K digits) outputs: Invalid format on line 1 and then some 100 lines with Code: Length is beyond length of decimal on line 1Length is beyond lengt h of decimal on line 1Length is beyond length of decimal on line 1Length is beyond length of decimal on line 1Length is beyond length of decimal on line 1Length is beyond length of Aside from that spam, it picks up at the correct point and seems to continue without further problems. Edit: No, it doesn't always continue, sometimes it just stops with 'Invalid format on line 1' When I have time, I will test some more. Last fiddled with by J F on 2016-06-11 at 13:02

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Mersenne Primes p which are in a set of twin primes is finite?	carpetpool	Miscellaneous Math	3	2017-08-10 13:47
Distribution of Mersenne primes before and after couples of primes found	emily	Math	34	2017-07-16 18:44
Conjecture about Mersenne primes and non-primes v2	Mickey1	Miscellaneous Math	1	2013-05-30 12:32
A conjecture about Mersenne primes and non-primes	Unregistered	Information & Answers	0	2011-01-31 15:41
possible primes (real primes & poss.prime products)	troels munkner	Miscellaneous Math	4	2006-06-02 08:35

2016-06-03, 13:53	#166
ATH Einyen Dec 2003 Denmark 3⁵·13 Posts	31415926535897932384...89830932080370010789 is Lucas PRP! (70233.3140s+30.6992s) (613373 digits)

2016-06-03, 17:39	#168
ATH Einyen Dec 2003 Denmark C57₁₆ Posts	It is not my find, I was just adding a Lucas test on it. See post #143-#146. Though I have been working on PiPrimes. I got up to around 350k digits, but I guess I was too late

2016-06-03, 20:53	#169
rogue "Mark" Apr 2003 Between here and the 6347₁₀ Posts	I have posted pixsieve 2.1 here. It will now output files in the DECIMAL format which is supported by pfgw 3.8.1. That makes for much smaller files and a lot less I/O. The ability to continue from a previously sieved file now works, so you can start a sieve with pixsieve -P1e8 -l20000 -L30000 -C20000 -oterms.out -spi.txt -t4 -S15 then continue with pixsieve -P1e9 -iterms.out -oterms.pfgw -t4. The last prime in the range is written to the terms file so restarting will not require you to specify -p. Also the -F option has changed. Like the terms file (-o) this will expect a file name. That file will also be written in the DECIMAL format so that pfgw can verify factors. The only caveat with -F is that it will always overwrite any pre-existing file, so be careful with that if you want to verify factors.