-   XYYXF Project (
-   -   Leyland Primes (x^y+y^x primes) (

pxp 2020-07-11 09:43

[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=""]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.

kar_bon 2020-07-16 09:28

I've included more than 330 Leyland numbers in the Wiki showing in the [url='']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='']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.

pxp 2020-07-16 22:17


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.

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.

pxp 2020-07-17 19:03

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=""]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.

rogue 2020-07-17 22:53

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.

pinhodecarlos 2020-07-19 21:44

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

rogue 2020-07-20 03:24

[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.

NorbSchneider 2020-07-23 17:36

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

pxp 2020-07-23 22:48

[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=""]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.

rogue 2020-07-24 01:25

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.

pxp 2020-08-06 12:31

[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=""]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=""]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.

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

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.