mersenneforum.org Primes in π
 Register FAQ Search Today's Posts Mark Forums Read

 2016-06-03, 13:53 #166 ATH Einyen     Dec 2003 Denmark 1100011001112 Posts 31415926535897932384...89830932080370010789 is Lucas PRP! (70233.3140s+30.6992s) (613373 digits)
2016-06-03, 15:22   #167
CRGreathouse

Aug 2006

3×1,993 Posts

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?

 2016-06-03, 17:39 #168 ATH Einyen     Dec 2003 Denmark 1100011001112 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 144368 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.
 2016-06-04, 20:59 #170 J F     Sep 2013 1110002 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, 00:25   #171
rogue

"Mark"
Apr 2003
Between here and the

2·5·643 Posts

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.

 2016-06-05, 08:59 #172 J F     Sep 2013 23×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 23×7 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
2016-06-11, 13:58   #174
rogue

"Mark"
Apr 2003
Between here and the

2×5×643 Posts

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.

2016-06-13, 16:20   #175
rogue

"Mark"
Apr 2003
Between here and the

2×5×643 Posts

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.

2016-07-06, 16:01   #176
rogue

"Mark"
Apr 2003
Between here and the

2×5×643 Posts

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.

 Similar Threads Thread Thread Starter Forum Replies Last Post carpetpool Miscellaneous Math 3 2017-08-10 13:47 emily Math 34 2017-07-16 18:44 Mickey1 Miscellaneous Math 1 2013-05-30 12:32 Unregistered Information & Answers 0 2011-01-31 15:41 troels munkner Miscellaneous Math 4 2006-06-02 08:35

All times are UTC. The time now is 17:49.

Wed Oct 20 17:49:33 UTC 2021 up 89 days, 12:18, 0 users, load averages: 1.21, 1.20, 1.24