Leyland Primes (x^y+y^x primes)

[NorbSchneider]

Another new PRP:
37535^37674+37674^37535, 172338 digits.

[lghu]

My 'Leyland-1M' project found this PRP:

211185^54364+54364^211185 is Fermat and Lucas PRP!

1000027 digits, index: 21589915517 (if my program is correct).

[pxp]

Originally Posted by lghu

My 'Leyland-1M' project found this PRP:
211185^54364+54364^211185 is Fermat and Lucas PRP!
1000027 digits, index: 21589915517 (if my program is correct).

Well done! The Leyland-number index is correct. I have a dictionary of Leyland (x,y) pairs from (999999,10) to (1000999,10), sorted by magnitude and preceded by its Leyland-number index (21588818851 to 21628375832), so I can just look it up.

[pxp]

Originally Posted by pxp

The date in my list is not from the FactorDB list but (primarily) the date used in PRPtop which is month/year. This is because I endeavoured to date all Leyland primes > 10000 digits, not just the ones that made it to FactorDB (quite a few did not). Even so, I had issues because not everyone submitted their primes to PRPtop. Where I could, I added missing primes to PRPtop on the person's behalf, but in these cases the PRPtop date would be somewhat later than the actual discovery date (which I gleaned from the mersenneforum thread) so I used the actual discovery dates. For a smallish number of primes I had no discovery date, so I used an estimate based on other similar-sized numbers contributed to PRPtop by the author. For my own contributions where I actually had a precise day of discovery, a couple of last-day-of-the-month finds show up in PRPtop dated the following month because I didn't submit them before midnight (PRPtop time). In those cases I used PRPtop months: close enough! In only one instance — Anatoly Selevich's L(8656,2929) — did I not have sufficient evidence of a probable discovery date. It may have been removed from PRPtop after it was proven prime (I resubmitted it in 2015). I went through Anatoly's submissions to PRPtop and finally settled on November 2007 as the most likely date of that find, although the evidence is far from certain. That is why in my Leyland primes indexing list, the date for L(8656,2929) is the only one preceded by a "~".

715 38951950 30008 (8656,2929) Anatoly Selevich ~Nov 2007 P

I have just now changed this line to:

715 38951950 30008 (8656,2929) Anatoly Selevich Dec 2007 P

I don't know why I hadn't thought of this before. The Internet Archive Wayback Machine has a Jan 2008 snapshot that definitively dates the PRP discovery.

[NorbSchneider]

Another new PRP:
33^129128+129128^33, 196083 digits.

[NorbSchneider]

Another new PRP:
37803^37916+37916^37803, 173562 digits.

[storm5510]

Originally Posted by NorbSchneider

Another new PRP:
37803^37916+37916^37803, 173562 digits.

37803 ^ 37916 + 37916 ^ 37803 = ?

[paulunderwood]

Originally Posted by storm5510

37803 ^ 37916 + 37916 ^ 37803 = ?

http://factordb.com/index.php?showid...00003609777732

[storm5510]

Originally Posted by paulunderwood

http://factordb.com/index.php?showid...00003609777732

Sorry, I asked the wrong question.

What are these calculation being done with?

[paulunderwood]

Originally Posted by storm5510

Sorry, I asked the wrong question.

What are these calculation being done with?

mtsieve + OpenPFGW is my guess

[rogue]

He has a special build of xyyxsieve because the way he is testing ranges is based upon decimal length of the candidates. The "out of the box" xyyxsieve is more efficient with a relatively square workspace, i.e. the range of x and y are similar in size. At one time I was working on changing xyyxsieve to be provide the "best of both worlds", but I couldn't get it to work and gave up. I might return to it someday.

The biggest challenge with xyyxsieve is that it is most efficient to sieve a very large search space once than to break that up into smaller chunks. But with a very large search space one needs a lot of memory.