Another new PRP:
15770^17589+17589^15770, 73836 digits.

[QUOTE=pxp;524687]That makes L(40182,47) #1348 and advances the index to L(31870,131), #1354.[/QUOTE]

I have examined all Leyland numbers in the four gaps between L(31870,131) <67478>, #1354, and L(34684,105) <70103> and found 37 new primes. That makes L(34684,105) #1395.

[QUOTE=pxp;527845]That makes L(34684,105) #1395.[/QUOTE]

I have examined all Leyland numbers in the four gaps between L(34684,105) <70103>, #1395, and L(29356,257) <70746> and found 4 new primes. That makes L(29356,257) #1403.

Another new PRP:
1239^26228+26228^1239, 81126 digits.

Another new PRP:
12352^18043+18043^12352, 73828 digits.

Another new PRP:
15010^17699+17699^15010, 73918 digits.

Another new PRP:
14596^17691+17691^14596, 73670 digits.

Another new PRP:
2067^25516+25516^2067, 84595 digits.

[QUOTE=NorbSchneider;530401]Another new PRP...[/QUOTE]

Norbert posts these so that I don't accidentally submit to PRPtop the same number, on the smallish chance that I have come across it before PRPtop lists it. Because Norbert and I use different approaches as to which Leyland numbers to test for primality, there is some overlap that allows this to happen, although I will say that the closest I have come to rediscovering one of his primes is about two weeks. I don't know how close he has come to rediscovering one of mine.

I don't post my individual finds here of course, feeling that it is sufficient to post them to PRPtop and update [URL="http://chesswanks.com/num/a094133.txt"]my indexed list[/URL]. As I write, there is a captcha timeout error that prevents me from posting my two most recent finds to PRPtop so I will note these with an asterisk in my list, until such a time as the issue is resolved.

A quick check of the XYYXF site shows it has not been updated in almost three years. Anyone know what's happening?

[QUOTE=xilman;530500]A quick check of the XYYXF site shows it has not been updated in almost three years. Anyone know what's happening?[/QUOTE]

I have stated previously here (page 25) that "Andrey Kulsha has been missing (I'm guessing that he died) since his last update in January 2017."

I wonder. Have you done a google search? Could this be him: [url]https://scholar.google.com/citations?user=ye4rUDkAAAAJ&hl=en?[/url] It was updated this year.

Maybe he forgot or got bored or no longer has access.

[QUOTE=rogue;530513]I wonder. Have you done a google search? Could this be him: [url]https://scholar.google.com/citations?user=ye4rUDkAAAAJ&hl=en?[/url] It was updated this year.

Maybe he forgot or got bored or no longer has access.[/QUOTE]

Good call. I emailed both authors of the paper and Dmitry Sharapa already got back to me:


"Last time I received message from Andrey 1.September 2019, it was related to our paper. After that we did not keep any contact.

I would not be over pessimistic about him without more significant proves for following reasons:
He also took active part in 'chemport.ru' forum and there are no posts from him after 4.August 2019, but system claims that his last visit to that forum was just yesterday.
To my knowledge he married last summer, so he might have some other activities.

Anyway I sent him message in Slack (was our way of communication during work on the project) and if he will answer - I’ll let you know."

Hope Andrey comes back. I tried to keep the faith, monitored Yoyo’s efforts and added any surviving composite cofactors to the end of the queue after an ECM hit. Looks like all XYYXF numbers will be tested to the full t55 level within the next few months.

Also hoping to get a few of the C3XX numbers into the 16e queue. Several have been tested to the t65+ level now.

It would be really nice to have Andrey back!

[/rambling nonsense]

From Andrey:

"I'm still alive but deeply buried into computational chemistry. I still hope that XYYXF project will resurrect sometime :)"

[QUOTE=pxp;530573]From Andrey:

"I'm still alive but deeply buried into computational chemistry. I still hope that XYYXF project will resurrect sometime :)"[/QUOTE]Perhaps I should mail him asking how much he knows about driving DIRAC. I'm technically computing the energies and line strengths of the FeH spectrum but haven't worked on it for ~3 years now. Astronomy took over.

[QUOTE=pxp;530573]From Andrey:

"I'm still alive but deeply buried into computational chemistry. I still hope that XYYXF project will resurrect sometime :)"[/QUOTE]

Maybe he could give you or someone else update access to the website or maybe it could be moved elsewhere. With Russia building its own internet, who knows how long it will be before that site is not accessible to anyone outside of Russia.

[QUOTE=rogue;530590]Maybe he could give you or someone else update access to the website or maybe it could be moved elsewhere. With Russia building its own internet, who knows how long it will be before that site is not accessible to anyone outside of Russia.[/QUOTE]Err...

It's not in Russia.

[QUOTE=xilman;530598]Err...

It's not in Russia.[/QUOTE]

I assumed that this site, [url]http://www.primefan.ru/xyyxf/default.html[/url], is in Russia.

[QUOTE=rogue;530600]I assumed that this site, [url]http://www.primefan.ru/xyyxf/default.html[/url], is in Russia.[/QUOTE]Hmm. AFAIK, Andrey is, or was, in Belarus. I assumed that his site was located there too.

Oh well.

[QUOTE=pxp;528543]That makes L(29356,257) #1403.[/QUOTE]

I have examined all Leyland numbers in the seven gaps between L(29356,257) <70746>, #1403, and L(30280,241) <72128> and found 12 new primes. That makes L(30280,241) #1422.

[QUOTE=pxp;530464]As I write, there is a captcha timeout error that prevents me from posting my two most recent finds to PRPtop so I will note these with an asterisk in my list, until such a time as the issue is resolved.[/QUOTE]

The PRP Top submission issue appears to be fixed. I just added 12 Leyland PRPs.

[QUOTE=pxp;530726]That makes L(30280,241) #1422.[/QUOTE]

I have examined all Leyland numbers in the two gaps between L(30280,241) <72128>, #1422, and L(104824,5) <73269> and found 14 new primes. That makes L(104824,5) #1438.

Another new PRP:
2223^25780+25780^2223, 86285 digits.

Another new PRP:
1828^25929+25929^1828, 84580 digits.

Another new PRP:
15927^18196+18196^15927, 76463 digits.

Another new PRP:
2551^26056+26056^2551, 88766 digits.

[QUOTE=pxp;532355]That makes L(104824,5) #1438.[/QUOTE]

I have examined all Leyland numbers in the eight gaps between L(104824,5) <73269>, #1438, and L(30247,300) <74926> and found 24 new primes. That makes L(30247,300) #1470.

[QUOTE=pxp;520920]I count 160 unindexed primes in my list. I'm going to be adding some more cores to the project next month, so I'm looking forward to seeing what the number will be in six months.[/QUOTE]

So it is six months later and the number of unindexed primes is still 160. Clearly I did not appreciate when I wrote the above that new prime finds beyond the intervals in which I test every Leyland number are keeping pace with unindexed terms in those intervals that subsequently acquire indices. This situation is not likely to change appreciably for another 14 months (or so) when I finally bridge to the primes with ~100000 decimal digits.

Another new PRP:
17275^18246+18246^17275, 77316 digits.

Another new PRP:
2618^26175+26175^2618, 89466 digits.

Another new PRP:
2996^26241+26241^2996, 91228 digits.

Another new PRP:
18090^18307+18307^18090, 77941 digits.

Another new PRP:
18226^18359+18359^18226, 78223 digits.

Another new PRP:
2816^26445+26445^2816, 91226 digits.

Trivia
 

Of the currently 1671 known Leyland primes, only one has an L(x,y) where x and y are (base-10) anagrams of each other.

[QUOTE=pxp;534815]That makes L(30247,300) #1470.[/QUOTE]

I have examined all Leyland numbers in the four gaps between L(30247,300) <74926>, #1470, and L(40089,82) <76723> and found 22 new primes. That makes L(40089,82) #1496.

Another new PRP:
2126^26511+26511^2126, 88218 digits.

Another new PRP:
19690^19941+19941^19690, 85632 digits.

Another new PRP:
1036^27529+27529^1036, 83010 digits.

An [URL="http://gladhoboexpress.blogspot.com/2020/03/my-500th-leyland-prime-find.html"]update[/URL] on my ongoing prime search. The bad news is that I am not likely (as previously hoped) to finish by this time next year.

Another new PRP:
1949^27666+27666^1949, 91016 digits.

[QUOTE=pxp;540503]The bad news is that I am not likely (as previously hoped) to finish by this time next year.[/QUOTE]

I am now past the six-month mark of my [URL="http://gladhoboexpress.blogspot.com/2020/04/half-way.html"]upper-half of interval #14 search[/URL]. Click the link if you are curious to see what this looks like on the three Mac minis that are running the calculation.

Another new PRP:
1738^26881+26881^1738, 87096 digits.

Another new PRP:
21269^21412+21412^21269, 92666 digits.

Another new PRP:
21537^21634+21634^21537, 93745 digits.

Another new PRP:
1137^27908+27908^1137, 85281 digits.

Another new PRP:
21675^21796+21796^21675, 94507 digits.

[QUOTE=pxp;538161]That makes L(40089,82) #1496.[/QUOTE]

I have examined all Leyland numbers in the seven gaps between L(40089,82) <76723>, #1496, and L(32160,329) <80954> and found 62 new primes. That makes L(32160,329) #1565.

[QUOTE=pxp;520920]I am now keeping a backup copy on my Google Drive that will hopefully be accessible a little longer than the file on my computer[/QUOTE]

My [URL="http://chesswanks.com/num/a094133.txt"]Leyland prime indexing page[/URL] has a new [URL="https://drive.google.com/file/d/1K-fMKMXQsBlXixlp8toY7Xpvno00m9fU/view"]Google Drive backup[/URL] URL.

Just for safety I am dropping a snapshot of that file here as a zip.

This page, [url]http://www.primefan.ru/xyyxf/primes.html#0[/url], is not being updated. Where is the status of the search being maintained?

Is there a table with a list of all ranges that have been checked, who checked them, and when?

I'm asking because if someone wants to participate, they would have difficulty knowing where to start.

[QUOTE=rogue;548824]This page, [url]http://www.primefan.ru/xyyxf/primes.html#0[/url], is not being updated. Where is the status of the search being maintained?[/QUOTE]

Andrey Kulsha's effort is a snapshot of when it was last maintained (January 2017) and is unlikely to be updated. In terms of probable primes, the difference between it and my [URL="http://chesswanks.com/num/a094133.txt"]Leyland prime indexing page[/URL] is that, as of this moment, Norbert Schneider has added an additional 66 PRPs and I have added an additional 449. The L(x,y) PRP search is currently decoupled from its x/y dependency to the extent that size matters. Indexing is possible because all x^y+y^x of a given digit-size are being probed. For example, all Leyland primes smaller than 80965 decimal digits are now known. The cost of that knowledge is that the already-probed x's and y's are all over the place.

Still, one can say that once we have reached 81300 digits, x needs to be greater than 19000, or when we have reached 86025 digits, x needs to be greater than 20000, and so on. If my indexing effort reaches 105130 digits (which seems doable by 2022), x will need to be greater than 24000. That would be one thing to keep in mind if one wishes to participate. A second thing is that for larger x up to 50000, y has supposedly been checked up to 800. For larger x up to 500000, y has supposedly been checked up to 25. Just pick something. There's unlikely to be any duplication. If you know how to sort (x,y) pairs by L(x,y) digit-size, even better. You can pick a range of digit-sizes and contribute what you find. If you really want a challenge, find the next-larger PRP after Serge Batalov's L(328574,15). It will immediately become the largest-known Leyland prime.

[QUOTE=pxp;548870]The cost of that knowledge is that the already-probed x's and y's are all over the place.[/QUOTE]

That is my issue.

Are you saying that once you reach x = 19000 that all y < x have been searched for those x?

Is the intention to "not trust" what others have done and just retest all y < x for the range of x?

The table at the top of [url]http://www.primefan.ru/xyyxf/primes.html#0[/url] is really useful, but is useless since it is out of date. Why can't you just have a copy of that on your page and keep it up to date? It shouldn't be hard unless you are purely focused on "decimal length" as your goals instead of the goals of the original project.

If you are focused purely on "decimal length" goals does that mean that for each x you are searching to a different y? If so, are you even using xyyxsieve? Are you sieving then manipulating the output to "skip" x/y values larger than the decimal length you are searching for?

For me this all started in April 2015 when I computed a table of the first 5000 Leyland numbers (OEIS [URL="http://oeis.org/A076980"]A076980[/URL]). At the same time I realized that I could do something similar with the Leyland primes and thus contributed a table of the first 100 Leyland primes (OEIS [URL="http://oeis.org/A094133"]A094133[/URL]). I wondered how many of the then-1092 known Leyland primes were indexable and thus I extended my prior calculation of the first 100 Leyland primes to the first 954 Leyland primes. In May 2015 I used my result to curve-fit the Leyland number indices of those 954 Leyland primes and determined that the largest-known Leyland prime L(328574,15) would have a Leyland prime index of ~5550. That meant that there were thousands of [I]smaller[/I] Leyland primes waiting to be discovered. It also meant that because everyone was so focused on this x/y reservation scheme, I might be able to find new, relatively-small primes by examining the Leyland numbers [I]between[/I] existing Leyland primes. Thus began my Leyland prime hunt.

The basis of the hunt was my creation of a database of the first 331682621 Leyland numbers. That would include [I]all[/I] Leyland numbers up to 100000 digits. They were represented as (x,y) pairs and sorted by L(x,y) size. I would step through these pairs in Mathematica one at a time, testing each one for GCD[x,y]==1 before doing PrimeQ[L(x,y)]. That's it. No sieving and I never worry about where the x or the y are at. Yes, that's important when one is distributing a computation and need to keep track of who is doing what. I just never bought into that since I was pursuing my own goal of indexing the Leyland primes. And to that extent I feel good about what I have accomplished. Those initial 954 indexed primes are now 1567 indexed primes. Of those 613 added indices, 422 are for primes that I have discovered. I knew when I started this project that I might be stepping on some toes and for that I apologize. On the other hand, as I have tried to point out, there is nothing preventing folk from stepping out of their comfort zone and continuing the dance to a new beat.

Then the original search and yours are like comparing apples to oranges.

If someone wants to work on ranges for the original project, but not redo your work, then would have difficulty knowing where to start.

If you are not sieving, then you are probably wasting a ton of time trial factoring and PRP testing. What you can do is sieve with xyyxsieve, then use a script to pare done the terms that are outside of the decimal length you are searching.

The idea of using a script already makes it unlikely that xyyxsieve would be a fit for my lack of programming skills (I've used Mathematica for 24 years and I still have to regularly look stuff up). Are you saying that if I wanted to search for Leyland primes from just above Serge Batalov's L(328574,15) to, say, L(80332,71590) [64138108 Leyland numbers that run from 386434 digits to 390000 digits; I [I]have[/I] a 1 GB text file of the size-sorted (x,y) pairs] I would first have to use xyyxsieve to cull candidates from all Leyland numbers up to some incredibly large term and then throw out the ones that are less than 386434 digits or more than 390000 digits? How does one feed xyyxsieve so that it is guaranteed to include [I]every[/I] Leyland number candidate in that range? What might be the memory requirement to do that?

[QUOTE=pxp;548994]The idea of using a script already makes it unlikely that xyyxsieve would be a fit for my lack of programming skills (I've used Mathematica for 24 years and I still have to regularly look stuff up). Are you saying that if I wanted to search for Leyland primes from just above Serge Batalov's L(328574,15) to, say, L(80332,71590) [64138108 Leyland numbers that run from 386434 digits to 390000 digits; I [I]have[/I] a 1 GB text file of the size-sorted (x,y) pairs] I would first have to use xyyxsieve to cull candidates from all Leyland numbers up to some incredibly large term and then throw out the ones that are less than 386434 digits or more than 390000 digits? How does one feed xyyxsieve so that it is guaranteed to include [I]every[/I] Leyland number candidate in that range? What might be the memory requirement to do that?[/QUOTE]

You would have to know the range of x and y, to feed into the program. Let it run for an hour or two to thin out the range. I would expect that 75% or more of starting terms will be removed. This will obviously have terms with more or fewer decimal digits than what you need. If you do not know how to write a script, ask someone to write a script to cull the terms you don't want to test. There are a few people on this forum that have such a skill. Just ask and someone will likely step up to the plate for you. Take the culled file and use that as input to xyyxsieve to continue sieving until the average time to remove a term is close to the time it takes to do a PRP test.

Assuming you have multiple cores for testing, I suggest that you set up a PRPNet server. Once a server is set up this is by far the fastest way to distribute work across multiple cores and multiple computers. You don't need programming skill to run PRPNet. You will need to install MySQL or PostgreSQL and create a database. I can help you with that. It isn't as hard as you might think.

If this is just a matter of finding terms that I want to test, I can and have already done that in Mathematica. For example, there are only 17632 Leyland numbers greater than Serge Batalov's L(328574,15) that have exactly 386434 decimal digits. Selecting those that have GCD(x,y) = 1 reduces this to 10808 terms. Subjecting these numbers to Mathematica's PrimeQ (which is Mathematica's PRP test) for at most one second per term reduces our candidate list to [URL="http://chesswanks.com/num/LLPHbdl/386434.txt"]1324 terms[/URL]. PrimeQ has a built-in small-primes divisor test and I think one second per term is enough to run that part of it. Still, that requires about 4 minutes on my old 2013 Mac and I've been reluctant to apply it to the entire database of 64138108 Leyland numbers (386434 digits to 390000 digits). I did however create similar lists of [URL="http://chesswanks.com/num/LLPHbdl/386435.txt"]386435-digit terms[/URL] and [URL="http://chesswanks.com/num/LLPHbdl/386436.txt"]386436-digit terms[/URL] just as a proof of concept. The nice thing about the lists is that the entries are ordered by L(x,y) magnitude (every term is larger than its immediate predecessor).

For me the hard part is actually doing a full PRP test on the numbers. PrimeQ[L(85085,34812)] took over 6 hours on my main machine, albeit all 4 of its cores are busy on another project. I would not be surprised that there is software that can do this much faster. But lacking such, it would take me 11 months to test the entire first list. If my Mac-mini farm weren't already engaged, I could do it in a week. But that is one list. There will be 3567 such lists to get up to 390000 digits.

[QUOTE=pxp;549149]If this is just a matter of finding terms that I want to test, I can and have already done that in Mathematica. For example, there are only 17632 Leyland numbers greater than Serge Batalov's L(328574,15) that have exactly 386434 decimal digits. Selecting those that have GCD(x,y) = 1 reduces this to 10808 terms. Subjecting these numbers to Mathematica's PrimeQ (which is Mathematica's PRP test) for at most one second per term reduces our candidate list to [URL="http://chesswanks.com/num/LLPHbdl/386434.txt"]1324 terms[/URL]. PrimeQ has a built-in small-primes divisor test and I think one second per term is enough to run that part of it. Still, that requires about 4 minutes on my old 2013 Mac and I've been reluctant to apply it to the entire database of 64138108 Leyland numbers (386434 digits to 390000 digits). I did however create similar lists of [URL="http://chesswanks.com/num/LLPHbdl/386435.txt"]386435-digit terms[/URL] and [URL="http://chesswanks.com/num/LLPHbdl/386436.txt"]386436-digit terms[/URL] just as a proof of concept. The nice thing about the lists is that the entries are ordered by L(x,y) magnitude (every term is larger than its immediate predecessor).

For me the hard part is actually doing a full PRP test on the numbers. PrimeQ[L(85085,34812)] took over 6 hours on my main machine, albeit all 4 of its cores are busy on another project. I would not be surprised that there is software that can do this much faster. But lacking such, it would take me 11 months to test the entire first list. If my Mac-mini farm weren't already engaged, I could do it in a week. But that is one list. There will be 3567 such lists to get up to 390000 digits.[/QUOTE]Perhaps it is time for me to spend some more cpu on this project, for the first time in ten years or so.

Unfortunately I am busy factoring Generalized Cullen and Woodall numbers. Just one of those is expected to take me more than a year unless others help me. I no longer have the cpu power that I used to have.

pfgw will likely be faster since it is based upon the gwnum library. I suggest that you run and compare to the PrimeQ function of Mathematica. I do not have Mathematica, so I cannot compare its speed with pfgw. Since I have 2013 MacBook Pro, I'm guessing that pfgw is about 2x faster than Mathematica, given the information you have when using PrimeQ.

I'll make you an offer. Send me one of your lists and I'll sieve with xyyxsieve. I'll sieve to the appropriate depth and send the list back to you. That way both of us can see how much time it could save your project. If there is overlap between x and or y in the lists, send me all of your lists and I can see how xyyxsieve handles doing it all in one chunk.

[QUOTE=rogue;549154]Send me one of your lists and I'll sieve with xyyxsieve.[/QUOTE]

Did you mean (for example) my original 17632 Leyland number pairs list that I reduced to [URL="http://chesswanks.com/num/LLPHbdl/386434.txt"]1324 candidate terms[/URL]? Why not just sieve the 1324 terms?

Also, since I am not at all acquainted with xyyxsieve, is the output format of my list appropriate? I have one round-bracketed (x,y) pair per line with a final empty line to indicate end-of-file. I can lose the brackets or make other changes that might make feeding xyyxsieve easier.

I can work with that file. I just need to manipulate with NotePad++ to be compatible with xyyxsieve.

Here is a sample run of xyyxsieve:

[code]
xyyxsieve -y100 -Y2000 -x1000 -X1900 -s+ -P1e6
xyyxsieve v1.5, a program to find factors numbers of the form x^y+y^x
Quick elimination of terms info (in order of check):
856401 because the term is even
162236 because x and y have a common divisor
Sieve started: 3 < p < 1e6 with 694164 terms (1000 <= x <= 1900, 100 <= y <= 2000) (expecting 638964 factors)
p=432389, 604.0 p/sec, 654967 factors found at 10.75K f/sec, 43.2% done. ETC 2020-06-27 10:40
Sieve completed at p=1000193.
Processor time: 93.38 sec. (0.00 sieving) (1.00 cores)
36802 terms written to xyyx.pfgw
Primes tested: 78512. Factors found: 657362. Remaining terms: 36802. Time: 93.27 seconds.
[/code]

The first few lines of xyyx.pfgw look like this:

[code]
ABC $a^$b$c*$b^$a // Sieved to 1000193
1000 319 +1
1000 341 +1
[/code]

which sorted by ascending x then ascending y.

The input has a restriction that maxy must be greater than maxy. I really don't recall why.

If you have the command line tools with Xcode, you can build xyyxsieve fairly easily as a makefile is included.

[QUOTE=rogue;549154]pfgw will likely be faster ...[/QUOTE]

If I can get it to run. After spending a considerable amount of time trying to unzip the Mac-version download (it defaulted to some really old unarchivers I had squirreled away that couldn't do it), I finally downloaded a more recent app that did the job. Generally on modern Macs one can unzip a .zip file just by double-clicking on it.

Following the Beginner's Manual, I created the shown "input.txt" file and placed it in the "distribution" folder that contained "pfgw64". Double-clicking on pfgw64 opened Terminal and ran through the license and usage text (press enter or ^C). I think I learned that ^C actually means Ctrl-C. The final 'enter' (or ^C any time) always ended with a logout, after which I couldn't type my "pfgw input.txt" or anything else for that matter.

[QUOTE=pxp;549259]If I can get it to run. After spending a considerable amount of time trying to unzip the Mac-version download (it defaulted to some really old unarchivers I had squirreled away that couldn't do it), I finally downloaded a more recent app that did the job. Generally on modern Macs one can unzip a .zip file just by double-clicking on it.

Following the Beginner's Manual, I created the shown "input.txt" file and placed it in the "distribution" folder that contained "pfgw64". Double-clicking on pfgw64 opened Terminal and ran through the license and usage text (press enter or ^C). I think I learned that ^C actually means Ctrl-C. The final 'enter' (or ^C any time) always ended with a logout, after which I couldn't type my "pfgw input.txt" or anything else for that matter.[/QUOTE]

For the .7z extension, I use Keka to compress/de-compress.

What you need to do is open the Terminal app (Applications/Utilities). Move pfgw64 to a folder that you can access easily from the command line. It is probably under /Users/<your user id>/Downloads or /Users/<your user id>/Downloads/distribution. From there you can execute pfgw64 by typing "./pfgw64" (without the double-quotes) and hitting the enter key. I suggest typing "./pfgw64 -q100^101+101^100" just to verify that it runs a PRP test on that term. Once you get that far, then you just have to replace "-q100^101+101^100" with the name of a file in a pfgw compatible format. The format I showed above is compatible with pfgw.

Once you get a little familiar with the Terminal app (think Unix or Linux), it opens up a world of possibilities for other command line applications such as the mtsieve suite and llr.

If you have other questions, please ask. If I cannot help, there are other Mac users on this forum who can.

In trying to run xyyxsieve against your file it has issues because there each x has only one y term. With such a large range of x and y, it cannot hold everything in memory.

It would require a custom sieve to avoid excessive memory usage if one wants to do the whole range at once.

I don't know if these candidates have been sieved or not or how deeply Mathematica will trial factor them to. I took a small chunk and sieved to 1e8 and reduced from 307 terms to 97 terms in about 4 minutes. It can clearly sieve more deeply. Sieving to 1e10 should reduce that to about 78 terms.

If you see value in using xyyxsieve, let me know and I'll see what I can do to "whip up" a special version for your search. A "special version" would be memory friendly and twice as fast, if not faster.

[QUOTE=rogue;549282]From there you can execute pfgw64 by typing "./pfgw64" ...[/QUOTE]

Thank you so much for explaining this. I had actually used ./ on other programs before but I use Terminal so infrequently that I forgot. So I ran this on my 2013 Mac Pro which was already running PrimeQs on six separate Mathematica programs:

[CODE]85085^34812+34812^85085 is composite: RES64: [13D0B9CBFDEA3D81] (3520.8900s+0.0050s)[/CODE]

Under an hour, compared to the 6 hours it had previously taken in Mathematica. I'm blown away!

[QUOTE=rogue;549286]If you see value in using xyyxsieve, let me know and I'll see what I can do to "whip up" a special version for your search. A "special version" would be memory friendly and twice as fast, if not faster.[/QUOTE]

Yes, please. I do have access to 32GB RAM on most of my machines so memory may not be that critical. Thanks for doing this.

[QUOTE=pxp;549321]Yes, please. I do have access to 32GB RAM on most of my machines so memory may not be that critical. Thanks for doing this.[/QUOTE]

I hacked a more optimized version of xyyxsieve (I should call it pxpsieve :smile:) that would work for your search.

Here is the command line output from a run with that input file (running on Windows):

[code]
xyyxsieve -i xyyx.in -P1e9
xyyxsieve v1.5, a program to find factors numbers of the form x^y+y^x
Sieve started: 2 < p < 1e9 with 1324 terms (78917 <= x <= 283782, 23 <= y <= 78832) (expecting 1280 factors)
p=994644191, 12.85K p/sec, 978 factors found at 70.36 sec per factor, 99.5% done. ETC 2020-06-28 19:06
Sieve completed at p=1000000009.
Processor time: 3830.22 sec. (0.03 sieving) (0.96 cores)
345 terms written to xyyx.pfgw
Primes tested: 50847536. Factors found: 979. Remaining terms: 345. Time: 3984.89 seconds.
[/code]

It was removing about 1 term per 70 seconds when it terminated. You can sieve until it takes about an hour to remove terms. I'm guessing somewhere close to 1e10. The output sieved to 1e9 is attached.

I estimate that you can fully sieve and PRP test this file of terms in about 16 days.

This was with AVX code (not AVX512), so only an AVX CPU will get that speed. If you don't have AVX, it will be slower. I estimate about 4x slower. I could probably double the non-AVX speed, but I assume that most people will run on a CPU that has AVX.

The OpenCL code has not been updated, but it could cut the time of sieving in half, thus allowing you to sieve more deeply.

Is this ready? Where do I download?

[QUOTE=pxp;549363]Is this ready? Where do I download?[/QUOTE]

Do you want a Windows build or OS X build? Or do you want the source so that you can build it on your own?

I would like a ready-to-run OS X build.

[QUOTE=pxp;549380]I would like a ready-to-run OS X build.[/QUOTE]

Try this.

I renamed my 1324 (x,y) list xyyx.in and put it in the same folder as xyyxsieve:

[CODE]./xyyxsieve -i xyyx.in -P1e9
xyyxsieve v1.5, a program to find factors numbers of the form x^y+y^x
Fatal Error: Can only continue from input file[/CODE]

If I change the file to xyyx.txt:

[CODE]Fatal Error: Unable to open input file[/CODE]

My terminal is running GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin18).

[QUOTE=pxp;549389]I renamed my 1324 (x,y) list xyyx.in and put it in the same folder as xyyxsieve:

[CODE]./xyyxsieve -i xyyx.in -P1e9
xyyxsieve v1.5, a program to find factors numbers of the form x^y+y^x
Fatal Error: Can only continue from input file[/CODE]

If I change the file to xyyx.txt:

[CODE]Fatal Error: Unable to open input file[/CODE]

My terminal is running GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin18).[/QUOTE]

You need to convert your input file to the ABC example shown earlier. That should be fairly easy to do with any text editor. You will want to start with -p2 to double-check all small primes.

[QUOTE=rogue;549391]You need to convert your input file to the ABC example shown earlier. That should be fairly easy to do with any text editor. You will want to start with -p2 to double-check all small primes.[/QUOTE]

I'm flying totally blind here. I have obviously never used xyyxsieve before and have limited experience using Terminal. The program you shared has no documentation. The only reference that I see to an ABC example is in the output file you shared three days ago:

[CODE]ABC $a^$b$c*$b^$a // Sieved to 1000193
1000 319 +1
1000 341 +1[/CODE]

Unfortunately that tells me nothing about how to convert my input file. Should I just be using x^y+y^x instead of (x,y) for every line? I had asked about making changes to my file to make the input better and your response was simply "I can work with that file," which suggested to me that no changes were necessary.

So your file is like
[code]
(85085,34812)
(92856,14509)
[/code]

Do this with a text editor:
- remove the "("
- remove the ")"
- replace the "," with " +1 " (notice the spaces)

Now the file should look like this
[code]
85085 +1 34812
92856 +1 14509
[/code]

Now insert as first line
[code]
ABC $a^$c$b*$c^$a // Sieved to 1000193
[/code]
Perhaps change the sieve depth.
This file now works with pfgw, try this with the sieve then.

PS:
Seems xyyxsieve don't like the file format, do the same with this
- remove the "("
- replace "," with " " (space)
- replace the ")" with " +1" (notice spaces)

and the first line as
[code]
ABC $a^$b$c*$b^$a // Sieved to 1000193
[/code]

[QUOTE=pxp;549412]I'm flying totally blind here. I have obviously never used xyyxsieve before and have limited experience using Terminal. The program you shared has no documentation.

Unfortunately that tells me nothing about how to convert my input file. Should I just be using x^y+y^x instead of (x,y) for every line? I had asked about making changes to my file to make the input better and your response was simply "I can work with that file," which suggested to me that no changes were necessary.[/QUOTE]

The typical usage of my sieves is that the user has used that sieve to start a new sieve from scratch and in doing so are familiar with the command line options (via -h) and the output format (ABC, ABCD, etc, for use with pfgw or llr).

In your case you are not starting "from scratch" so usage isn't quite so clear. The error "Can only continue from input file" is odd. -i provides the name of the file. if that file doesn't exist then you get the other error. If this happens again, I suggest you remove the space after the -i and use "-ixyyx.in" (for example).

I think you have enough detail to get started, but if not, please reach out to me.

I'm not making any progress. The error appears even after requesting help:

[CODE]./xyyxsieve -h
xyyxsieve v1.5, a program to find factors numbers of the form x^y+y^x
-h --help prints this help
-p --pmin=P0 sieve start: P0 < p (default 3)
-P --pmax=P1 sieve end: p < P1 (default 2^62)
-w --worksize=w primes per chunk of work (default 10000)
-W --workers=W start W workers (default 1)
-A --applyandexit apply factors and exit (used with -I)
-i --inputterms=i input file of remaining candidates
-I --inputfactors=I input file with factors (used with -A)
-o --outputterms=o output file of remaining candidates
-O --outputfactors=O output file with new factors
-x --minx=x minimum x to search
-X --maxx=X maximum x to search
-y --miny=y minimum y to search
-Y --maxy=Y maximum y to search
-D --disableavx disableavx
Fatal Error: Can only continue from input file[/CODE]

[QUOTE=pxp;549465]I'm not making any progress. The error appears even after requesting help:

[CODE]./xyyxsieve -h
xyyxsieve v1.5, a program to find factors numbers of the form x^y+y^x
-h --help prints this help
-p --pmin=P0 sieve start: P0 < p (default 3)
-P --pmax=P1 sieve end: p < P1 (default 2^62)
-w --worksize=w primes per chunk of work (default 10000)
-W --workers=W start W workers (default 1)
-A --applyandexit apply factors and exit (used with -I)
-i --inputterms=i input file of remaining candidates
-I --inputfactors=I input file with factors (used with -A)
-o --outputterms=o output file of remaining candidates
-O --outputfactors=O output file with new factors
-x --minx=x minimum x to search
-X --maxx=X maximum x to search
-y --miny=y minimum y to search
-Y --maxy=Y maximum y to search
-D --disableavx disableavx
Fatal Error: Can only continue from input file[/CODE][/QUOTE]

Right. You have to specify your input file with -i. That is required. Some of the others are not needed because of this special build. -P is only needed to stop sieving as some pre-determined depth. If you don't specify, it it will sieve until 2^62, which you won't need to do. While running it will give you the removal rate once per minute so you can get an idea if the removal rate is close to the PRP test time.

[QUOTE=rogue;549427]... remove the space after the -i ...[/QUOTE]

I think I've got a handle on the ABC format now. But the space (or lack thereof) between the -i and the file name makes no difference to fatality.

Largest Leyland Prime Hunt
 

I have replaced the previously referenced first three pages of Leyland prime candidates > L(328574,15) with versions that are now ABC format as opposed to my original (x,y) format. They are also significantly larger files as I have undone my own attempt at sieving in Mathematica since xyyxsieve will do so better/faster.

[url]http://chesswanks.com/num/LLPHbdl/386434.txt[/url]
[url]http://chesswanks.com/num/LLPHbdl/386435.txt[/url]
[url]http://chesswanks.com/num/LLPHbdl/386436.txt[/url]

the first three lines of the first page look like this:

[CODE]ABC $a^$b$c*$b^$a
164287 225 +1
102503 5888 +1[/CODE]

The numbers in the URL are the number of decimal digits in the L(x,y) expansions of the candidates. I have files ready to be shared going all the way up to /390000.txt (3567 pages). A .zip version of the entire folder is ~252 MB.

Every page starts out as a list of Leyland numbers. There are ~18000 such for each decimal-digits length in this range. Apparently there is a 16k line limit in ABC-formatted files so I reduced this to ~11000 lines by applying GCD(x,y)=1 to the (x,y) pairs. These were then printed out as the above-mentioned files.

As previously shown, a small-primes sieve will reduce the 11000 candidates to ~1300 and a deeper run to ~300. As Mark mentioned, a pfgw run of these would take about two weeks or so.

Since I'm presently unable to participate because the OS X xyyxsieve created by Mark for this purpose is not cooperating, I thought I'd just put this out there as the germ of an idea for future consideration. If there is something wrong with my ABC formatting or there is something else that needs attention (like the file-name ending, .txt or .in, does it matter?), please let me know. It takes very little time to re-generate the pages from scratch.

[QUOTE=pxp;549520]I have replaced the previously referenced first three pages of Leyland prime candidates > L(328574,15) with versions that are now ABC format as opposed to my original (x,y) format. They are also significantly larger files as I have undone my own attempt at sieving in Mathematica since xyyxsieve will do so better/faster.

[url]http://chesswanks.com/num/LLPHbdl/386434.txt[/url]
[url]http://chesswanks.com/num/LLPHbdl/386435.txt[/url]
[url]http://chesswanks.com/num/LLPHbdl/386436.txt[/url]

the first three lines of the first page look like this:

[CODE]ABC $a^$b$c*$b^$a
164287 225 +1
102503 5888 +1[/CODE]

The numbers in the URL are the number of decimal digits in the L(x,y) expansions of the candidates. I have files ready to be shared going all the way up to /390000.txt (3567 pages). A .zip version of the entire folder is ~252 MB.

Every page starts out as a list of Leyland numbers. There are ~18000 such for each decimal-digits length in this range. Apparently there is a 16k line limit in ABC-formatted files so I reduced this to ~11000 lines by applying GCD(x,y)=1 to the (x,y) pairs. These were then printed out as the above-mentioned files.

As previously shown, a small-primes sieve will reduce the 11000 candidates to ~1300 and a deeper run to ~300. As Mark mentioned, a pfgw run of these would take about two weeks or so.

Since I'm presently unable to participate because the OS X xyyxsieve created by Mark for this purpose is not cooperating, I thought I'd just put this out there as the germ of an idea for future consideration. If there is something wrong with my ABC formatting or there is something else that needs attention (like the file-name ending, .txt or .in, does it matter?), please let me know. It takes very little time to re-generate the pages from scratch.[/QUOTE]

The ABC line needs to have "// Sieved to xxx" on the first line when used as input. This is probably the issue you are seeing. Nevertheless I can see if anything else is wrong.

[QUOTE=rogue;549524]The ABC line needs to have "// Sieved to xxx" on the first line when used as input. This is probably the issue you are seeing. Nevertheless I can see if anything else is wrong.[/QUOTE]

Adding the comment made no difference.

I noticed that the help file had sieve start "3" as the default, suggesting perhaps that -p2 might be an out of range argument. As a result, I reworked my shared pages to exclude [I]even[/I] L(x,y). That brings the number of terms per page down from ~11000 to ~7300. The first three lines of my [URL="http://chesswanks.com/num/LLPHbdl/386434.txt"]first page[/URL] are now:

[CODE]ABC $a^$b$c*$b^$a // Sieved to 3
102503 5888 +1
80340 64561 +1[/CODE]

rogue, can you post a sample file that works for you. Then pxp can run that to check his binary is OK, then change 1 thing at a time until it's doing what he wants. I've found that starting from a working example makes problem solving much easier.

Chris

Apparently I did not do a "make clean" before I did the make. The attached should work with the proper ABC file.

I also found an issue in avx_powmod that only impacts non-Windows builds. That is also fixed.

[code]
./xyyxsieve -ixyyx.in -p3 -P1e6
xyyxsieve v1.5, a program to find factors numbers of the form x^y+y^x
Sieve started: 3 < p < 1e6 with 1324 terms (78917 <= x <= 283782, 23 <= y <= 78832) (expecting 1219 factors)
Sieve completed at p=1000193.
Processor time: 13.87 sec. (0.00 sieving) (0.98 cores)
503 terms written to xyyx.pfgw
Primes tested: 78512. Factors found: 821. Remaining terms: 503. Time: 14.16 seconds.
[/code]

[QUOTE=rogue;549621]The attached should work with the proper ABC file.[/QUOTE]

[CODE]mm5:~ pxp$ cd /Users/pxp/Desktop/rogue
mm5:rogue pxp$ ./xyyxsieve -i386434.txt -p3 -P2e9
xyyxsieve v1.5, a program to find factors numbers of the form x^y+y^x
Sieve started: 3 < p < 2e9 with 7203 terms (78911 <= x <= 1283705, 2 <= y <= 78900) (expecting 6834 factors)

p=5957291, 4.586K p/sec, 6757 factors found at 1.52 sec per factor, 0.3% done. ETC 2020-07-03 06:54
p=10411189, 4.588K p/sec, 6768 factors found at 5.53 sec per factor, 0.5% done. ETC 2020-07-03 02:52
p=14994013, 4.595K p/sec, 6775 factors found at 8.68 sec per factor, 0.7% done. ETC 2020-07-03 01:09
p=24406297, 4.597K p/sec, 6785 factors found at 12.15 sec per factor, 1.2% done. ETC 2020-07-02 23:34
p=29201503, 4.594K p/sec, 6789 factors found at 15.19 sec per factor, 1.5% done. ETC 2020-07-02 23:08
p=34041223, 4.597K p/sec, 6794 factors found at 12.15 sec per factor, 1.7% done. ETC 2020-07-02 22:48
p=38899507, 4.573K p/sec, 6798 factors found at 15.18 sec per factor, 1.9% done. ETC 2020-07-02 22:33
p=43805231, 4.583K p/sec, 6800 factors found at 30.36 sec per factor, 2.2% done. ETC 2020-07-02 22:21[/CODE]

This is on one of my Mac minis. I'll let it run to the end. Thank you!

[QUOTE=pxp;549626]This is on one of my Mac minis. I'll let it run to the end. Thank you![/QUOTE]

You're welcome. Glad to be of service.

You can use ^C to stop at any time. The program will finish processing the current chunk, then save and exit.

If 2e9 isn't deep enough you can start sieving again using -ixyyx.pfgw. You will not need to use -p as it will grab the initial prime from the input file.

[CODE]Processor time: 22549.57 sec. (1.62 sieving) (0.99 cores)
333 terms written to xyyx.pfgw
Primes tested: 98222288. Factors found: 6870. Remaining terms: 333. Time: 22668.14 seconds.[/CODE]

I took this up to 5e9 which required an additional 8.5 hours and found 16 new factors, slightly less than 2 new factors per hour. On my Mac mini, a PRP-test of a number this size required half an hour, so roughly equivalent to what subsequent sieving might accomplish. I have replaced my three previously shared pre-sieved Leyland number files with their post-sieved outputs:

[url]http://chesswanks.com/num/LLPHbdl/386434.txt[/url]
[url]http://chesswanks.com/num/LLPHbdl/386435.txt[/url]
[url]http://chesswanks.com/num/LLPHbdl/386436.txt[/url]

They contain 317, 325, and 303 terms, respectively. I think I can PRP-test any one of these in under a week and I intend to try in the near future. But first I will generate more sieved pages.

I ran multiple terminal windows to generate the three files. My initial attempt at this ran off the same xyyxsieve, little realizing that the ongoing xyyx.pfgw files overwrote each other. So I ended up cloning the folder containing xyyxsieve and re-ran each terminal window off its own folder. I suppose a future version of xyyxsieve could output a .pfgw file with a name that matches the input file name.

[QUOTE=pxp;549691]I ran multiple terminal windows to generate the three files. My initial attempt at this ran off the same xyyxsieve, little realizing that the ongoing xyyx.pfgw files overwrote each other. So I ended up cloning the folder containing xyyxsieve and re-ran each terminal window off its own folder. I suppose a future version of xyyxsieve could output a .pfgw file with a name that matches the input file name.[/QUOTE]

You can have multiple tabs in a Terminal window or multiple Terminal windows.

You can override the name of the output file by using -o and specifying the file name.

[QUOTE=kar_bon;549419]So your file is like
[code]
(85085,34812)
(92856,14509)
[/code]Do this with a text editor:
- remove the "("
- remove the ")"
- replace the "," with " +1 " (notice the spaces)

Now the file should look like this
[code]
85085 +1 34812
92856 +1 14509
[/code][/QUOTE]
I didn't keep the track of the development you talk about here, but what is described by Karsten can be achieved with a single regex command using perl or any text editor that accepts regex search and replace. For example, to do this with pn2 or with notepad++, open a search/replace box, by pressing ctrl+f or ctrl+h or alt+r (depending on the program or OS or settings you have for shortcuts) or just take it from the menu, then go to replace tab, be careful to check the "regular expressions" box, then in the "find what" box type "^\((\d*),(\d*)\)$" (without quotes, grrrr! how do I tell the forum's matjax not to mess with my expression? what a crakpot haha, he thinks this is math :razz:...Should I use "code" tags?) and in the "replace with" box type "\1 +1 \2" (without quotes, and mind the spaces around the "+1"). Click "replace all.

To have the plus at the end, just use "\1 \2 +1" in the "replace with" box.

For who didn't hear about regular expressions, this translates to "if you find two groups of any number of digits each, alone on the row (i.e. no other text, the ^ and $ signs represent beginning and end of the row) which are between parenthesis and separated by c comma, extract the the two groups in two different strings (called \1 and \2, this is what the internal parenthesis do, in the "find what" string) and rearrange them according with the "replace with" box, possibly adding some text (the +1 and spaces) around them". That's all. No magic.

Or, actually, Magic!
You still need to add the header line "ABC blah blah" by hand (i.e. typing :drama:)
Edit: picture (Notepad++ used for exemplification) because Mathjax messed my expression, I know there was a way to block this, which Serge wrote here in the past, but we forgot the tag... was it "noeval", or what?
[ATTACH]22701[/ATTACH]


One more observation, in Notepad++ the regex search/replace is undo-able (if you mess the expression, just press undo and retry till you learn the right way)

[QUOTE=pxp;549691]
[url]http://chesswanks.com/num/LLPHbdl/386434.txt[/url]
[url]http://chesswanks.com/num/LLPHbdl/386435.txt[/url]
[url]http://chesswanks.com/num/LLPHbdl/386436.txt[/url]

They contain 317, 325, and 303 terms, respectively. I think I can PRP-test any one of these in under a week and I intend to try in the near future. But first I will generate more sieved pages.[/QUOTE]

There are now 45 sieved pages available for Leyland prime candidates larger than L(328574,15), running from 386434 to 386478 decimal digits. Just replace the number in the URL with the number of decimal digits you want. I have started a pfgw test on the last six of those pages (386473-386478) and I realize now that my previous estimate of 30 minutes per term was incorrect. It is closer to 48 minutes. The difference, I believe, is likely due to the fact that running six pfgw tests concurrently throttles the single-pfgw-test processor speed back to its base value. So this will take 10-11 days for me total.

I don't of course expect to find a PRP. It strikes me as unlikely that any of the 45 pages will yield one. But don't let that put you off willing to look. Every eliminated page brings us closer to that eventual new largest-known Leyland prime.

Am I correct in thinking you are sieving each digit length separately? Is there any advantage in doing this? How does combining digit lengths affect sieve speed?

[QUOTE=henryzz;550164]Am I correct in thinking you are sieving each digit length separately? Is there any advantage in doing this? How does combining digit lengths affect sieve speed?[/QUOTE]

Sorting Leyland numbers by digit-length — more properly, by absolute magnitude — has been my obsession from the get-go. Mark hacked the existing program to accommodate any Leyland-number input file, including my sorted ones.

[QUOTE=pxp;546254]That makes L(32160,329) #1565.[/QUOTE]

I have examined all Leyland numbers in the four gaps between L(32160,329) <80954>, #1565, and L(40495,114) <83295> and found 37 new primes. That makes L(40495,114) #1606 and advances the index to L(39070,143), #1621.

[URL="http://chesswanks.com/num/a094133.txt"]Getting there![/URL] Before devoting myself more fully to interval #10, I'm going to use some of my resources to finish off (eliminate the gaps) in the second half of interval #14. Thank you again, Mark, for allowing me to add [I]xyyxsieve[/I] and [I]pfgw[/I] to my arsenal. It's been nothing short of transformative.

I've included more than 330 Leyland numbers in the Wiki showing in the [url='https://www.rieselprime.de/ziki/Leyland_prime_P_table']table[/url].

There're currently 1814 from your last file with data given by FactorDB (only year-month in your file).

I would appreciate if you could insert new finds by your own, it's not that complicated.

The sorting of the Wiki table (default by #digits) is way better than a text file and there's also a page with CSV-like data if it's needed [url='https://www.rieselprime.de/ziki/Leyland_prime_P_csv']here[/url].
Every number page contains the direct link to FactorDB for others to prove primality.
Not yet updated the graph of known Leyland numbers, I have to do other things than that first.

[QUOTE=kar_bon;550753]

There're currently 1814 from your last file with data given by FactorDB (only year-month in your file).

I would appreciate if you could insert new finds by your own, it's not that complicated.
[/QUOTE]

I will address the two points quoted.

I have year-month-day data for all of my own finds and these may differ from data garnered from FactorDB. I've only looked at a few of my early finds and, for example, #964 & #965 in the PrimeWiki gives 2016-01-29 whereas they were actually found Jan. 12 & Jan. 16, respectively. Of course that would be local time (EST). The same uncertainty would be true of any other date for any other finder. It is for this reason that early on I decided to only provide month & year. Not because this isn't without its own complications (some of my finds are listed in the next month if they were found sufficiently late in day of the last day of the previous month) but rather because it gives people a more accurate sense that dates are approximate without explicitly having to state that this is so.

Of course inserting new finds into the Wiki may not be that complicated. However, my current obsession is barely manageable. As I transfer my discovery process from Mathematica to xyyxsieve & pfgw, I'm doing a lot more manual intervention. Interval #10 required the creation of 420 ABC files, each of which must be dropped into the appropriate folder on the appropriate computer for the sieving, and then these must be attended to again for the pfgw. I am currently generating four new finds a day which must be carefully recorded and processed. These actions are necessarily staggered and I have shifted some sleep over the last week into daytime naps as I try to efficiently deal with this overabundance of work.

Mind, I'm not complaining. But the accuracy of my effort is contingent upon my maintaining focus. There is little hurry, in my opinion, to rush new finds into an alternate database.