Trouble in paradise
 

[QUOTE=pxp;549870]There are now 45 sieved pages available for Leyland prime candidates larger than L(328574,15), running from 386434 to 386478 decimal digits.[/QUOTE]

In addition to running pfgw tests on the last six of those pages (which still have a day-and-a-half to go), I did pfgw tests on the first three pages on my slightly faster iMac. These have now completed and present me with a serious conundrum. It appears that not every listed ABC candidate makes it to the terminal's printout window!

For example, 386435.txt starts:

[CODE]ABC $a^$b$c*$b^$a // Sieved to 5000000039
99942 7355 +1
82356 49231 +1
83128 44531 +1[/CODE]

but the printout starts:

[CODE]Recognized ABC Sieve file:
ABC File
82356^49231+1*49231^82356 is composite: RES64: [BA5198663B3CF789] (2043.1510s+0.0043s)
83128^44531+1*44531^83128 is composite: RES64: [5294950B96166D7C] (2043.5881s+0.0040s)[/CODE]

The first number is missing. I was able to reproduce the bug in another attempt at the file. Out of the 325 number-lines in the ABC file, only 304 are listed (as composite) in the Terminal window, so 21 are missing. The sorted x values of the missing numbers are 96876, 96975, 97305, 97416, 97532, 97588, 97983, 98217, 98483, 98568, 98676, 99205, 99287, 99561, 99942, 132767, 133413, 135502, 144321, 158214, 182231. Out of the sorted list of all candidate x values, these 21 are at the end, interrupted however by 28 x values from 100045 to 125411.

In yet another go at the file, I watched it compute the initial "PRP: 99942^7355+1*7355^99942 progress#/1283705" until completion. At this point something appeared in the terminal window (too fast for me to see what it said) but that was quickly overwritten by the computation of the next line. I ran it again with just the one line:

[CODE]Recognized ABC Sieve file:
ABC File
99942^7355+1*7355^99942 is composite: RES64: [239A42181330D58D] (1529.9585s+0.0030s)[/CODE]

So it was composite but that got overwritten. What if it had been prime? Would that have gotten overwritten and no log file generated for the prime find? Because of that possibility, I have put a brake on my current computations and have deleted indices #1568-#1621 from my [URL="http://chesswanks.com/num/a094133.txt"]indexing page[/URL] with an eye to possibly redoing my last twelve days of intense effort, this time verifying that all ABC candidate number-lines [I]do[/I] in fact appear in the Terminal window output.

If prime or PRP pfgw will add a newline so that you can see it. Also PRPs and primes are written to log files.

If you want to see all results including residues, then use -Cverbose on the command line.

How do I run these sieve files under LLR? Client is saying invalid ABC format.

[QUOTE=pinhodecarlos;551056]How do I run these sieve files under LLR? Client is saying invalid ABC format.[/QUOTE]

For now use pfgw. I will have to make a code change so that it can write llr compatible files.

Another new PRP:
1316^28233+28233^1316, 88066 digits.

[QUOTE=rogue;550881]If prime or PRP pfgw will add a newline so that you can see it. Also PRPs and primes are written to log files.

If you want to see all results including residues, then use -Cverbose on the command line.[/QUOTE]

When I first started using pfgw I played with the Terminal window size until what I saw seemed to me what I thought was supposed to be seen. Terminal was wrapping the output so that all results appeared (and I did not use the -Cverbose). I don't know if this was some unknown Terminal preference or because of a specific window size that I subsequently made default but after I encountered the overwrite weirdness I started to use an output file ("input.txt > output.txt") and began to realize that there were no hard wraps in the output except after a PRP (\n). Instead there was this \x{0D} thing which I can only assume is an overwrite of some sort. At any rate, since I am now religiously using the output-file directive I am using that file to do a double-check of found PRPs, as well as total of PRPs + composites = ABC input lines.

And I have now finished double-checking my initial pfgw finds for interval #9 and everything is fine. So I have added back indices #1568 - #1621 to [URL="http://chesswanks.com/num/a094133.txt"]my list[/URL]. I could extend the indices a bit further since I have done the initial third of interval #10 but I will instead wait until I have finished the entire interval. A double-check of the initial third of interval #10 and the second-half of interval #14 is ongoing and will take some more days. That large gap between L(22634,20265) <97479> and L(22845,19112) <97807> had me wondering if I had made some copy/paste or drag/drop error in my initial enthusiasm, so the Terminal weirdness wasn't the only thing making me re-examine my results.

Somewhere along the way I discovered that xyyxsieve is not limited to ABC files having a maximum of 16000 lines as I had assumed from a reading of "abcfileformats" in the pfgw distribution. To wit: "The current maximum line length for an ABC, ABCD or ABC2 file is just under 16k." Did I misread that? It doesn't refer to the number of lines but rather the size of a single line? It was this mistaken belief that caused me to divide interval #10 into 420 parts. I am now dividing all of my intervals into exactly 36 parts which is much more manageable. 36 parts is what I had been doing in Mathematica so I already have the necessary "border" numbers for creating my ABC files.

There are two things I have been tracking since I started looking for (and finding) new Leyland primes. The first is the [I][I]date[/I][/I] of the find. The second is the order of discovery. I soon realized that when the find is close to midnight, the exact date is uncertain. Eventually I wrote into Mathematica a date/time stamp for its finds so that I might be more certain of the day. This also solved the issue of discovery order since the time stamps of finds on two separate computers (or in two programs on the the same computer) told me which preceded the other.

I have date/time stamps for PRPs in the pfgw log files. The first PRP in a specific sub-interval is the creation date/time for the log file itself which may be had by doing a get-info on it. Subsequent PRPs added to the file will generate a "modified" date/time for the file. The problem is (or rather might be) that once a third PRP is added, one loses the date/time for the second. A fourth addition will lose the stamp for the third. "Modified" only records the most recent alteration to the file. So the solution is that I will need to actually write down these date/time stamps fairly soon after they are created. Which means that I will need to examine the log files several times a day — but I was doing that anyways since I am constantly looking for new PRPs to add to my list.

16k is a line length, not a file length. I've used files many MB in size as input to pfgw.

Another option if you have multiple cores (or multiple computers) is to install PRPNet. That will generate log files with timestamps. PRPNet supports this type of project.

[QUOTE=pxp;550260]That makes L(40495,114) #1606 and advances the index to L(39070,143), #1621.[/QUOTE]

I have examined all Leyland numbers in the eight gaps between L(39070,143) <84209>, #1621, and L(91382,9) <87201> and found 31 new primes. That makes L(91382,9) #1660.

Intervals #11-#13 are not going to take overly long. The first half of #14 (the second half is done) is already being sieved and that should finish in two weeks. The pfgw on it will take another five weeks, so I might be done by October. In preparation, I've already indicated on [URL="http://chesswanks.com/num/a094133.txt"]my list[/URL] intervals #15-#18, running from 103013 to 121787 decimal digits. Before I tackle those I will likely do a search for Leyland primes between L(49878,755) and L(149999,10), so as to establish a new beachhead for my advance. In addition, I am (slowly) checking some [URL="http://chesswanks.com/num/LLPHbdl/LLPHbdl.txt"]largest-Leyland-prime-hunt[/URL] ABC files which I have sieved to 10^10 for (currently) digits 386434 to 386487. Much like a lottery, it's a lot of effort for little chance of a find. People are welcome to join in the search, although (unless you are running OS X) you may have to ask Mark for a pfgw build to handle the input files.

[QUOTE=pxp;552761]I will likely do a search for Leyland primes between L(49878,755) and L(149999,10), so as to establish a new beachhead for my advance.[/QUOTE]

I have added indicators for intervals #19-#21 to my list. I have also decided that the above mentioned "beachhead" is far too ambitious. My intended beachhead is now interval #21. I am still in the process of verifying my new list of Leyland numbers which runs from L(102999,10) to L(149999,10), 337553864 terms. A worthwhile guide is that for d > 11, L(d-1,10) is (likely) the smallest (base ten) d-digit term. The sorted-by-magnitude list will allow me to directly look up the Leyland number index of any (x,y) term in that range. It will also, of course, provide the seed (x,y) pairs needed to generate the ABC files for my intervals.

Another new PRP:
1678^28479+28479^1678, 91839 digits.

[QUOTE=pxp;552761]That makes L(91382,9) #1660.[/QUOTE]

I have examined all Leyland numbers in the six gaps between L(91382,9) <87201>, #1660, and L(35829,302) <88857> and found 27 new primes. That makes L(35829,302) #1693.

[QUOTE=pxp;553622]That makes L(35829,302) #1693.[/QUOTE]

I have examined all Leyland numbers in the two gaps between L(35829,302) <88857>, #1693, and L(37738,243) <90029> and found 20 new primes. That makes L(37738,243) #1715.

[QUOTE=pxp;552831]A worthwhile guide is that for d > 11, L(d-1,10) is (likely) the smallest (base ten) d-digit term.[/QUOTE]

I began to wonder if any of these L(x,10) is prime. I'm doing a run on a list that I didn't sieve particularly deeply and I can say that for x < 300000 the answer is none. Perhaps this had already been determined. Of the prime L(x,y) that have x > 50000, I count 13 (current) solutions: (57285,2), (58046,9), (63880,3), (78296,3), (91382,9), (99069,2), (104824,5), (125330,3), (222748,3), (234178,9), (255426,11), (314738,9), (328574,15). All small y, which makes me wonder how far the discoverers allowed x to go (and for which y).

I've put a compilation of small-y solutions (y <= 1000) [URL="http://chesswanks.com/num/LeylandPrimes(small-y).txt"]here[/URL].

[QUOTE=pxp;554366]That makes L(37738,243) #1715.[/QUOTE]

I have examined all Leyland numbers in the two gaps between L(37738,243) <90029>, #1715, and L(38030,249) <91128> and found 17 new primes. That makes L(38030,249) #1734 and advances the index to L(37614,265), #1735.

[QUOTE=pxp;552831]My intended beachhead is now interval #21.[/QUOTE]

I decided to take my sieving of interval #21 to 1e10 and that still has a couple of days to go. In the meantime I am pfgw-ing recently assigned (and already sieved) interval #28 [L(148999,10) - L(149999,10)] and have now my first hit therein:

33845^26604+26604^33845 is 3-PRP!

I'm not sure factordb.com will PRP this for me. I noticed that Norbert's PRPTop submissions for a couple of his larger Leyland primes has a list of prime-PRPs from prime 2 to 11. Which brings me to ask why pfgw default reports only 3-PRPs. How does one get it to do other primes? Is it even necessary?

[QUOTE=pxp;556213]I decided to take my sieving of interval #21 to 1e10 and that still has a couple of days to go. In the meantime I am pfgw-ing recently assigned (and already sieved) interval #28 [L(148999,10) - L(149999,10)] and have now my first hit therein:

33845^26604+26604^33845 is 3-PRP!

I'm not sure factordb.com will PRP this for me. I noticed that Norbert's PRPTop submissions for a couple of his larger Leyland primes has a list of prime-PRPs from prime 2 to 11. Which brings me to ask why pfgw default reports only 3-PRPs. How does one get it to do other primes? Is it even necessary?[/QUOTE]

Use -b to choose a different base for the PRP test.

[QUOTE=pxp;554968]That makes L(38030,249) #1734 and advances the index to L(37614,265), #1735.[/QUOTE]

I have examined all Leyland numbers in the ten gaps between L(37614,265) <91148>, #1735, and L(40210,287) <98832> and found 117 new primes. That makes L(40210,287) #1862 and advances the index to L(40945,328), #1930.

That completes interval #14 which I did in two parts. The second (larger Leyland numbers) part, which I did first, ended up with 69 PRPs. Because the first (smaller Leyland numbers) part started off with roughly an identical quantity (~21919300) of Leyland numbers as the second part, I was expecting [I]at least[/I] 69 PRPs in it as well, but it ended up with only 57 PRPs.

I'm well on my way to completing (likely by October 12th) intervals #15, #16, and #28.

I have written a small program that converts pxp's text list of x^x+y^x primes/prps into an html table that has sortable columns. The source and html that it generates is attached.

[QUOTE=rogue;557874]I have written a small program that converts pxp's text list of x^x+y^x primes/prps into an html table that has sortable columns.[/QUOTE]

Thank you. Fortunately I had written a note to myself from the last time I ran a .cpp program.

[CODE]g++ xyyx.cpp -o xyyx

xyyx.cpp:60:56: warning: format specifies type 'unsigned long long *' but the argument has type 'long *'
[-Wformat]
if (sscanf(ptr, "%u %llu %u (%u,%u)", &index, &leylandNumber, &length, &x, &y) != 5)
[/CODE]

The [I]%llu[/I] and [I]&leylandNumber[/I] were underlined. This was followed by a very similar warning ending in [I]!=4[/I] and finally a third one relating to an [I]fprintf[/I] item containing the two offending variables. In spite of the warnings the created xyyx ran to create a list.html from a list.txt.

I can probably run this every time I update my [URL="http://chesswanks.com/num/a094133.txt"]a094133.txt[/URL] document and share it [URL="http://chesswanks.com/num/a094133.html"]here[/URL]. A couple of minor issues: Christ van Willegen and Jens Kruse Andersen have lost their surnames and Göran Hemdal has lost the umlauted o (I assume that it is visible in the .txt version).

[QUOTE=pxp;557892]Thank you. Fortunately I had written a note to myself from the last time I ran a .cpp program.

[CODE]g++ xyyx.cpp -o xyyx

xyyx.cpp:60:56: warning: format specifies type 'unsigned long long *' but the argument has type 'long *'
[-Wformat]
if (sscanf(ptr, "%u %llu %u (%u,%u)", &index, &leylandNumber, &length, &x, &y) != 5)
[/CODE]

The [I]%llu[/I] and [I]&leylandNumber[/I] were underlined. This was followed by a very similar warning ending in [I]!=4[/I] and finally a third one relating to an [I]fprintf[/I] item containing the two offending variables. In spite of the warnings the created xyyx ran to create a list.html from a list.txt.

I can probably run this every time I update my [URL="http://chesswanks.com/num/a094133.txt"]a094133.txt[/URL] document and share it [URL="http://chesswanks.com/num/a094133.html"]here[/URL]. A couple of minor issues: Christ van Willegen and Jens Kruse Andersen have lost their surnames and Göran Hemdal has lost the umlauted o (I assume that it is visible in the .txt version).[/QUOTE]

Try compiling with -m64. A long is 64-bits with -m64 but only 32-bits for -m32 and I assume that the default for the compiler is -m32.

I treat the input as ASCII, so it is likely losing the umlaut in his name. I'm not certain how to fix that.

The code assumes only two portions of the name. It would be easy to fix the parsing in the code to address that.

[QUOTE=rogue;557924]Try compiling with -m64.[/QUOTE]

Yes, if only I knew how to do that. Is it really that important? What does my warnings-ignored [URL="http://chesswanks.com/num/a094133.html"]converted document[/URL] lack that a properly compiled conversion file would have?

[QUOTE=pxp;557991]Yes, if only I knew how to do that. Is it really that important? What does my warnings-ignored [URL="http://chesswanks.com/num/a094133.html"]converted document[/URL] lack that a properly compiled conversion file would have?[/QUOTE]

You can change the datatype from "long" to "long long" to remove the warning that you showed.

Another new PRP:
452^50145+50145^452, 133142 digits.

[QUOTE=pxp;557387]I have examined all Leyland numbers in the ten gaps between L(37614,265) <91148>, #1735, and L(40210,287) <98832> and found 117 new primes. That makes L(40210,287) #1862 and advances the index to L(40945,328), #1930.[/QUOTE]

I have examined all Leyland numbers in the gap between L(40945,328) <103013>, #1930, and L(41507,322) <104094> and found 14 new primes. That makes L(41507,322) #1945.

I have examined all Leyland numbers in the gap between L(148999,10) <149000> and L(149999,10) <150000> and found 14 new primes.

[QUOTE=pxp;558416]That makes L(41507,322) #1945.[/QUOTE]

I have examined all Leyland numbers in the three gaps between L(41507,322) <104094>, #1945, and L(222748,3) <106278> and found 38 new primes. That makes L(222748,3) #1986.

29652^5083+5083^29652 is 3-PRP

This was an accidental find, in other words, unexpected. I had removed x with fewer than 50 terms from the main sieve to test separately because sieving is less efficient with x that have few terms.

It's actually nice to see another name in the recents. I am still ten days away from discovering this one. Be sure to claim it on PRPTop so that they will be up-to-date.

[QUOTE=pxp;560317]It's actually nice to see another name in the recents. I am still ten days away from discovering this one. Be sure to claim it on PRPTop so that they will be up-to-date.[/QUOTE]

Submitted.

[QUOTE=pxp;554544]I began to wonder if any of these L(x,10) is prime. I'm doing a run on a list that I didn't sieve particularly deeply and I can say that for x < 300000 the answer is none.[/QUOTE]

I finished that run up to 500000 and then decided to do from there to 10^6. I sieved that file to 10^12 resulting in [URL="http://chesswanks.com/num/L(x,10).txt"]1309 candidates[/URL]. The durations total to 293.3 days but distributed equally over 12 cores, 24.4 days. Of course I didn't have the pfgw durations when I started so I guessed at the distribution, resulting in some of the segments taking considerably longer than others. Sadly, no PRPs.

Another new PRP:
419^52446+52446^419, 137525 digits.

[QUOTE=pxp;557892]I can probably run this every time I update my [URL="http://chesswanks.com/num/a094133.txt"]a094133.txt[/URL] document and share it [URL="http://chesswanks.com/num/a094133.html"]here[/URL]. A couple of minor issues: Christ van Willegen and Jens Kruse Andersen have lost their surnames and Göran Hemdal has lost the umlauted o (I assume that it is visible in the .txt version).[/QUOTE]

These pages are not loading today. Says the server is not responding

Thanks for the heads-up. Occasionally my internet service provider changes the number of my IP address. This happens rarely but without notice and since I access [URL="http://chesswanks.com"]chesswanks.com[/URL] locally I usually don't notice until someone complains. When it happens I have to go to DYNDNS and have the domain point to the new number, which I have now done.

I have examined all Leyland numbers in the gap between L(147999,10) <148000> and L(148999,10) <149000> and found 11 new primes.

[QUOTE=pxp;559405]That makes L(222748,3) #1986.[/QUOTE]

I have examined all Leyland numbers in the four gaps between L(222748,3) <106278>, #1986, and L(45405,286) <111532> and found 80 new primes. That makes L(45405,286) #2070.

That was interval #17. Interval #18 still has a month of sieving before I can even get a start on it. I'll be doing intervals #21, #25, and #26 until then.

Another new PRP:
208^52765+52765^208, 122313 digits.

Another new PRP:
13699^27268+27268^13699, 112800 digits.

I have examined all Leyland numbers in the gap between L(146999,10) <147000> and L(147999,10) <148000> and found 12 new primes.

Another new PRP:
13899^27442+27442^13899, 113692 digits.

Another new PRP:
13706^27459+27459^13706, 113596 digits.

The smallest k such that n^k+k^n is prime ([URL="https://oeis.org/A243147"]A243147[/URL])

[QUOTE=sweety439;566447]The smallest k such that n^k+k^n is prime ([URL="https://oeis.org/A243147"]A243147[/URL])[/QUOTE]

47 is 40182, known since Nov 2014. Why is 27 a zero?

[QUOTE=pxp;566573]47 is 40182, known since Nov 2014. Why is 27 a zero?[/QUOTE]

There is [I]no possible[/I] prime for 27

27^n+n^27 = (3^n)^3+(n^9)^3 and a^3+b^3 can be factored as (a+b)*(a^2-a*b+b^2)

Similarly, no possible prime for n = (3*k)^3, (5*k)^5, (7*k)^7, (9*k)^9, (11*k)^11, ... (r*k)^r with odd r>1

Conjecture: There are infinitely many primes for all other n

[QUOTE=sweety439;566575]Conjecture: There are infinitely many primes for all other n[/QUOTE]Counterexample: If x = 4, the only integer y > 0 for which 4^y + y^4 is prime is y = 1.

Proof: If y > 1, and y is even, 4^y and y^4 are both divisible by 16, so the sum is divisible by 16.

If y > 1 and odd, say y = 2*k + 1, then 4^y = 4*(2^k)^4, whence 4^y + y^4 = (2*4^k - 2*y*2^k + y^2)* (2*4^k + 2*y*2^k + y^2) [and remember, y = 2*k + 1]

Both factors are greater than 1 for odd y, except for k = 0, y = 1.

Similarly with x = 4*m^4, x^y + y^x is either divisible by 16 or has an algebraic factorization.

[QUOTE=Dr Sardonicus;566589]Counterexample: If x = 4, the only integer y > 0 for which 4^y + y^4 is prime is y = 1.

Proof: If y > 1, and y is even, 4^y and y^4 are both divisible by 16, so the sum is divisible by 16.

If y > 1 and odd, say y = 2*k + 1, then 4^y = 4*(2^k)^4, whence 4^y + y^4 = (2*4^k - 2*y*2^k + y^2)* (2*4^k + 2*y*2^k + y^2) [and remember, y = 2*k + 1]

Both factors are greater than 1 for odd y, except for k = 0, y = 1.

Similarly with x = 4*m^4, x^y + y^x is either divisible by 16 or has an algebraic factorization.[/QUOTE]

Well, x = 4 (and y>1) proven composite by partial algebra factors (like 25*12^n-1, 27*12^n-1, 4*24^n-1, 6*24^n-1 in [URL="http://www.noprimeleftbehind.net/crus/Riesel-conjectures.htm"]Riesel conjectures[/URL])

Also for x = 64, 324, 1024, 2500, 5184, ... 4*m^4, since even y are divisible by 2 and odd y factored as a^4+4*b^4 (x^y is of the form 4*b^4 if x = 4*m^4, y is odd, and y^x is 4th power, since x is divisible by 4)

So the [URL="https://oeis.org/A243147/a243147.txt"]a-file[/URL] for A243147 is not right, n=64 should be "0" instead of "unknown"

I have examined all Leyland numbers in the gap between L(145999,10) <146000> and L(146999,10) <147000> and found 17 new primes.

I am going to be doing intervals #23 and #24, postponing #18 until late January.

Are there any test limit of y, for x=6 (6^y*y^6+1), x=10 (10^y*y^10+1), and x=13 (13^y*y^13+1)? There are no known primes for x=13, and the only known primes for x=6 and x=10 are 6^1*1^6+1 and 10^1*1^10+1

[QUOTE=sweety439;566753]Are there any test limit of y, for x=6 (6^y*y^6+1), x=10 (10^y*y^10+1), and x=13 (13^y*y^13+1)? There are no known primes for x=13, and the only known primes for x=6 and x=10 are 6^1*1^6+1 and 10^1*1^10+1[/QUOTE]
Looking for fish in the meat market?
What do these have to do with this thread?

Better start your own thread.

[QUOTE=Batalov;566759]Looking for fish in the meat market?[/QUOTE]

While I have you here, I've been wondering if you might prefer Sergey over Serge in my [URL="http://chesswanks.com/num/a094133.txt"]Leyland primes[/URL] indexing effort. It's an easy fix.

[QUOTE=pxp;566773]While I have you here, I've been wondering if you might prefer Sergey over Serge in my [URL="http://chesswanks.com/num/a094133.txt"]Leyland primes[/URL] indexing effort. It's an easy fix.[/QUOTE]
Sergey, thanks.

A word or two about that other prime class; one can modify existing sieves for that; just think of them as denominators of the x[SUP]y[/SUP]+y[SUP]-x[/SUP], so the changes to sieve code are evident.

Another new PRP:
27496^27577+27577^27496, 122422 digits.

I have examined all Leyland numbers in the gap between L(49205,532) <134129> and L(49413,580) <136550> and found 42 new primes.

I cannot access [url]http://chesswanks.com/num/a094133.html[/url].

Thank you. I had some wi-fi issues yesterday that interrupted the communication effort with my Mac-mini farm. In particular, one machine would not let me in over the network. In the past I have solved this by directly connecting (USB-C or crossover ethernet) an obstinate mini to my main computer but this time that did not work. As all of my minis are monitored via screen sharing, I ended up having to haul my living room TV to the mini (I did not want to do the reverse because I would have to unplug it and that would cease its current calculations). Bottom line: after I rebooted the mini's wi-fi I forgot to plug the ethernet cable back into my main machine (which hosts chesswanks).

Interval #18 has roughly twice as many terms (all of them larger) than did #17 (which took about six weeks to finish @ 30 cores). I'm currently idling (sieving and working on the largest-Leyland-prime hunt) those minis that are not engaged in doing intervals #23 and #24. That way when I do #18 I will use [I]all[/I] of my minis for the task and (hopefully) keep the compute time down.

I have examined all Leyland numbers in the gap between L(49878,755) <143547> and L(144999,10) <145000> and found 20 new primes.

Another new PRP:
27953^28198+28198^27953, 125381 digits.

I have examined all Leyland numbers in the gap between L(144999,10) <145000> and L(145999,10) <146000> and found 7 new primes.

I started interval #18 yesterday. It may be another three days before I can devote all of my cores to the task, as a couple of them are still finishing up previous assignments. I have a very provisional completion date of March 10.

Another new PRP:
28203^28352+28352^28203, 126175 digits.

Another new PRP:
28340^28503+28503^28340, 126907 digits.

Another new PRP:
28781^28930+28930^28781, 129002 digits.

[QUOTE=pxp;570016]I started interval #18 yesterday... I have a very provisional completion date of March 10.[/QUOTE]

It looks like I overestimated this by a week or so. In fact, a couple of my processors have already finished their assigned ranges and I have wasted no time getting them started on interval #19.

Another new PRP:
28659^28988+28988^28659, 129208 digits.

[QUOTE=pxp;563640]That makes L(45405,286) #2070.[/QUOTE]

I have examined all Leyland numbers in the eight gaps between L(45405,286) <111532>, #2070, and L(48694,317) <121787> and found 143 new primes. That makes L(48694,317) #2221.

I'm guessing that I have used pfgw64 on some 5 million Leyland numbers since I started using it back in early July of last year. This is the first error encountered (this morning) using it:

Expr = 34048^5655+1*5655^34048
Detected in MAXERR>0.45 (round off check) in prp_using_gwnum
Iteration: 197019/424418 ERROR: ROUND OFF 0.5>0.45
PFGW will automatically rerun the test with -a1

[QUOTE=pxp;573421]I'm guessing that I have used pfgw64 on some 5 million Leyland numbers since I started using it back in early July of last year. This is the first error encountered (this morning) using it:

Expr = 34048^5655+1*5655^34048
Detected in MAXERR>0.45 (round off check) in prp_using_gwnum
Iteration: 197019/424418 ERROR: ROUND OFF 0.5>0.45
PFGW will automatically rerun the test with -a1[/QUOTE]

That does happen, but is rare. Fortunately it tried with a different FFT size automatically.

Leyland primes curve fit
 

I was curious about how many more new primes I was going to find in my current interval (#19) as well as the two subsequent ones (#20 & #22) so I decided to do a more formal calculation instead of my usual ballpark estimates. I first used the approach [URL="http://gladhoboexpress.blogspot.com/2015/05/indexing-leyland-primes.html"]back in 2015[/URL] to calculate a best fit curve (y = Leyland number index = ax^b) for the then 954 Leyland prime indices that I believed were sequential and used that curve to decide that the prime index of L(328574,15) — still the largest known Leyland prime — would be ~5550.

I used the 2222 Leyland prime indices that I currently have as sequential to recalculate the best fit. In the attached, that curve is red, contrasted with a green curve for the 2015 calculation. The green curve actually holds up pretty well until we get to ~1800. The recalculated L(328574,15) now comes in at index ~5908. But I wanted to know how many new primes I was going to find in the next couple of months. For interval #19, the suggested total will be ~88 (I have 80 as I write with another week or so to go). Interval #20 will yield ~90 and #22, ~97.

[QUOTE=pxp;572777]That makes L(48694,317) #2221.[/QUOTE]

I have examined all Leyland numbers in the seven gaps between L(48694,317) <121787>, #2221, and L(44541,746) <127955> and found 111 new primes. That makes L(44541,746) #2339.

So much for my March 18th calculated prediction (for this interval) of only 88 new primes. I do update a [URL="http://chesswanks.com/num/a094133.html"]sortable-columns version[/URL] of my [URL="http://chesswanks.com/num/a094133.txt"]Leyland primes indexing page[/URL] when I finish an interval or find a prime with a [I]y[/I] smaller than 1000. But it's too much effort to update it every time I find a new prime as I have to make three corrections to the html after each page conversion.

[QUOTE=pxp;574615]That makes L(44541,746) #2339.[/QUOTE]

I have examined all Leyland numbers in the four gaps between L(44541,746) <127955>, #2339, and L(49205,532) <134129> and found 99 new primes. That makes L(49205,532) #2442 and advances the index to L(49413,580), #2485.

As my search of interval #22 winds down (ten or so day to go), I started (yesterday) the interval from L(299999,10) to L(300999,10). A preliminary estimate suggests that this will require some two-and-a-half months.

Another new PRP:
45^104608+104608^45, 172940 digits.

[QUOTE=pxp;577255]That makes L(49205,532) #2442 and advances the index to L(49413,580), #2485.[/QUOTE]

I have examined all Leyland numbers in the two gaps between L(49413,580) <136550>, #2485, and L(49878,755) <143547> and found 123 new primes. That makes L(49878,755) #2610 and advances the index to L(45728,1905), #2691.

I believe that we have now all Leyland primes/PRPs < 150000 decimal digits or, equivalently, all prime/PRP L(x,y), x < 33180.

Impressive compilation. Do you have data on which of the numbers are just PRPs? It would make a nice list of candidates for primo.

You can look at [url='https://www.rieselprime.de/ziki/Leyland_prime_P_table']this table[/url] for a list of unproven numbers. I've not looked at those for a longer time, so some are verified and a certificate is available at FactorDB.
Just updated only 3 numbers, see the recent changes.
Dates and program taken from FDB.

Ok, thanks.

Since I am no longer using the final column of my [URL="http://chesswanks.com/num/a094133.txt"]Leyland prime indexing chart[/URL] to indicate intervals, I've added a "P" therein for entries that I know are proven primes. That necessitated removing the "date approximate" for Selevich's L(8656,2929) and adding a "~" in front of that entry's date, which is how I had it originally. The indices of my chart are of course one greater than the indices of the Leyland "Prime Wiki" table because they are a reflection of OEIS [URL="http://oeis.org/A094133/b094133.txt"]A094133[/URL] which has a spurious first term.

Looking at that table, there are a lot of results that should be able to be proven in less than a day (at least) on "bigger" systems. Please correct me, if I am wrong here, frequent Primo users!

If correct, I'd like to reserve some of the smaller ones tomorrow for Primo. I will specify them futher then and also double check them on FactorDB.

In the list of kar_bon, maybe we should try to certify the "orange" entries, too?

[QUOTE=bur;580520]Impressive compilation. Do you have data on which of the numbers are just PRPs? It would make a nice list of candidates for primo.[/QUOTE]Not sure whether you realise this, but that's the reason why these numbers have been singled out and given a particular name.

Long ago I pointed out that they seem to have a reasonable density of primes of all sizes, have a very simple algebraic description and have no obvious properties which can be exploited by special-purpose algorithms.

Several have been used to set records for the size of a certified prime. They are frequently used, I believe, to test new implementations of general primality testing algorithms.

[QUOTE=kruoli;580617]If correct, I'd like to reserve some of the smaller ones tomorrow for Primo. I will specify them futher then and also double check them on FactorDB.[/QUOTE]

Excuse me for the delay. For now, I'd like to reserve only [URL="http://www.rieselprime.de/ziki/Leyland_prime_P_3222_553"]http://www.rieselprime.de/ziki/Leyland_prime_P_3222_553[/URL] and watch how long it takes on my machine. I guess that's better before I get overboard. After that finished, I'll report.

I found a new record for largest Leyland PRP
It is 386642 digits long (previous record is 386434 digits)
PRP: 81650^54369+54369^81650

[QUOTE=kruoli;580952]After that finished, I'll report.[/QUOTE]

It took around 18-20 h on a 5950X (all cores used). The certificate is uploaded. Who has to be informed to update the table? I guess we can wait with this until the numbers below are finished as well.

I'd like to reserve[LIST][*][$]L(3107, 712)[/$][*][$]L(3710, 303)[/$][*][$]L(5041, 70)[/$][*][$]L(3099, 1078)[/$][*][$]L(3782, 315)[/$][*][$]L(3784, 315)[/$][/LIST]for Primo certification next. This are the six smallest Leyland PRPs (unproven) currently.

[QUOTE=kruoli;582688]Who has to be informed to update the table?[/QUOTE]

I will update [URL="http://chesswanks.com/num/a094133.txt"]my table[/URL] as your results come in.

My reservations from above are now completed and are currently being processed by FactorDB. Thus, I'd like to reserve:[LIST][*][$]L(3178, 1005)[/$][*][$]L(3185, 1182)[/$][*][$]L(3171, 1256)[/$][*][$]L(3081, 1568)[/$][*][$]L(3070, 1781)[/$][*][$]L(4504, 165)[/$][*][$]L(6886, 29)[/$][/LIST]Since I already submitted some proofs to FactorDB for numbers which have been proven before independently but had no certificate on FactorDB, as soon as the above are completed, all Leyland primes below 10,000 digits will be certified in FactorDB. I checked this with a script; if I made some error, please correct me! :smile: [I]Edit: There are three certificates missing which I cannot upload currently. Sorry.[/I]

[SPOILER]As a personal side note, the last number in the list above will be my first 10k digit ECPP run. Knowing that this is not something impressive at all by itself, I am still pleased.[/SPOILER]

PS: I just saw FactorDB got a hardware upgrade. They now run:[LIST][*]CPU: AMD Ryzen 3700X[*]RAM: 2x16 GB[*]SSD: 3x1 TB RAID 5[/LIST]

Another new PRP:
457^60454+60454^457, 160803 digits.