Riesel base 6 - team drive #4 - EIGHT OR BUST!

[gd_barnes]

Originally Posted by Lennart

Here it is.

Will soon be back with the time on pfgw

Lennart


EDIT: 59095*6^435235-1 is composite: RES64: [9A8DA7CAF565D7ED] (2961.6498s+0.0260s)

on a q6600@2.4Ghz

Wow! We're spot on the exact optimum sieve depth for breaking off n=290K-500K. 2961 sec. test time vs. ~3000 sec. removal rate. What a lucky break that is. Therefore we need no more sieving up to n=500K. I would say the next break off should be for n=500K-750K so when we hit n>400K, we can PFGW a candidate at n=675K and compare that to the removal rate of sieving n=500K-1M to see how much more we need to sieve that range.

If we find no primes up to n=500K (heaven forbid!), a fairly accurate estimate for the removal rate is 3000 secs. * (1M-290K) / (1M-500K) = 4260 secs. and an estimate for a PFGW test at n=675K would be 2961 * (675K/435K)^2 = 7130 secs.

Therefore, a rough estimate of the optimum sieve depth for breaking off n=500K-750K assuming no primes up to n=500K is 7130 / 4260 * 32T = ~54T. So if that estimate is close, the additional sieving needed is not great compared to what we've (Lennart) has already done, even if we don't find a prime. If we do find one or more, we may not need to sieve at all! I've had this happen quite a few times when breaking off lower n-ranges on new bases that I start. It all depends on the density of primes you encounter and how high the max n-value / min n-value is in your sieve file. If that ratio is high, like it is here (1M/150K=6.67), frequently you won't have to sieve much further (or at all) for the higher n-ranges IF you've used the entire file for calculating your optimum sieve depth for the lower n-ranges, which is the correct thing to do IF you are actually going to test the entire file within a reasonable time frame.


Gary

[Mini-Geek]

59095*6^171929-1 is 3-PRP!

The primality test is running now.

Primality testing 59095*6^171929-1 [N+1, Brillhart-Lehmer-Selfridge]
Running N+1 test using discriminant 11, base 1+sqrt(11)
N+1: 59095*6^171929-1 32500/444447 mro=0.126953125

Lessee here... floor(171929*Log(10,6)+Log(10,59095)+1)=133792 digits, (where Log(x, y) = log(y)/log(x), which works out to be the base x log of y) which will place it at #4999 on the top 5000! Guess I should make a top-5000 code for CRUS quick! Edit: Prime "59095*6^171929-1" is too small (133792 digits). Need 134593 digits or more for a general prime. Awww, I just barely missed it being on the top-5000 (even if only for a moment).

[Lennart]

Originally Posted by Mini-Geek

59095*6^171929-1 is 3-PRP!

Congratulation

Lennart

[Mini-Geek]

300000/444447

Primality tests of base 6 numbers this large sure take a while...
This would've been my first non-NPLB and non-base 2 prime to make the top 5000, if only I had discovered it a wee bit sooner. Wasn't quite as down-to-the-wire as you may think, since I still had to run the lengthy primality test before submitting it.

[Batalov]

So we now should scratch all 59095 from our work files, right?

[mdettweiler]

All I can say is, it's about time!



I'll remove the k from the posted files but will hold off on uploading the new versions until the primality proof comes in.

I'll also remove it from my in-progress file for 260K-265K. Note to anyone else doing this: make sure you adjust the line # accordingly in pfgw.ini after removing anything from the input file. Otherwise, things can get messy.

Edit: @Batalov, yes.

[Batalov]

then better not delete them but stop the runners, "Replace 59095 to //59095", start 'em, right?


P.S. Kinda worked:
Resuming input file x.txt at line 69
Using zero-padded FFT length 80K on 78959*6^289478-1
Resuming at bit 325799
78959*6^289478-1 is composite: RES64: [24BB3383C8613258] (805.6220s+0.0150s)
#59095*6^289481-1 - Evaluator failed
Using zero-padded FFT length 80K on 43994*6^289482-1 ...etc

[Mini-Geek]

Primality testing 59095*6^171929-1 [N+1, Brillhart-Lehmer-Selfridge]
Running N+1 test using discriminant 11, base 1+sqrt(11)
59095*6^171929-1 is prime! (6022.6429s+0.0067s)

Originally Posted by Batalov

then better not delete them but stop the runners, "Replace 59095 to //59095", start 'em, right?

It'll say something like this:
//57023*6^174589-1 - Evaluator failed
and skip that line. No harm done, though it's not really how it should be. Also, it will probably mess up your current line progress, soo...might not really work for your purposes.

[mdettweiler]

Originally Posted by Batalov

then better not delete them but stop the runners, "Replace 59095 to #59095", start 'em, right?

Uh...no. I'm pretty sure that the ABC format does NOT accept comments on any other line than the first, and even there, they have to be preceded by "//", not by "#". You have to actually remove the numbers from the file.

The easiest way to do this is with the srfile utility, which is included with the srsieve sieving program. You can get srsieve at http://www.geocities.com/g_w_reynolds/srsieve/. Then, do the following:

-Shut down PFGW.

-Change the first line of the sieve file to "1:M:0:6:258". This essentially puts the file in NewPGen format, which is necessary because srfile doesn't support the particular type of ABC format we're using for this.

-Then, run srfile as follows:
srfile -d 59095*6^n-1 -G sieve-file-name.txt

-srfile will output the file with the removed k under the name t17_b6.prp. Open that file, and change the first line to "ABC $a*6^$b-1 // {number_primes,$a,1}".

-Now, locate the number in t17_b6.prp that was the one you were in the middle of testing when you shut down PFGW. If you were in the middle of testing something from k=59095, then find the next one after the one you were testing. Look at the line number for that test and write it down.

-Open pfgw.ini and change the line labeled "CurLineNum=" to the number you just wrote down.

-Delete the old sieve file, and rename t17_b6.prp to the old file's name.

-Start PFGW with the same command line you used when you first started your range.

That should do the trick. Note that if any of that seems to complex for you to handle, it won't hurt to just leave the k in. It's better to spend a few minutes more testing some extra numbers than it is to mess up and skip or re-test part of your range.

[mdettweiler]

To all: I've removed k=59095 from the posted files.

[Mini-Geek]

How does PFGW store its list of k's to skip? If that could be easily edited to include 59095, that'd be great.
Or, here's a simple trick you could do to get it to skip that k:
Stop PFGW
Open your sieve file in Notepad (or similar)
Delete all lines up to the candidate you're currently working on (leave the current one alone)
Put "59095 171929" on its own line at the top (below the header line, of course)
Start PFGW again

When you start PFGW back up, it'll see that the file changed and restart at line 2, find the PRP, then know to skip all with that k, then continue to the one you left off at and resume from its save file. The only downside is that you have to duplicate the few minutes (for me, 13.85 minutes in far-from-optimal conditions, probably closer to 10 minutes CPU time) to find that number is PRP, and do so for every instance of PFGW.