20200711, 09:43  #386 
Sep 2010
Weston, Ontario
266_{8} Posts 
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.
Getting there! 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 xyyxsieve and pfgw to my arsenal. It's been nothing short of transformative. 
20200716, 09:28  #387 
Mar 2006
Germany
2×1,427 Posts 
I've included more than 330 Leyland numbers in the Wiki showing in the table.
There're currently 1814 from your last file with data given by FactorDB (only yearmonth 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 CSVlike data if it's needed here. 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. Last fiddled with by kar_bon on 20200716 at 09:30 Reason: typo 
20200716, 22:17  #388  
Sep 2010
Weston, Ontario
2·7·13 Posts 
Quote:
I have yearmonthday 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 20160129 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. 

20200717, 19:03  #389  
Sep 2010
Weston, Ontario
2×7×13 Posts 
Trouble in paradise
Quote:
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:
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) 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) 

20200717, 22:53  #390 
"Mark"
Apr 2003
Between here and the
1011101111010_{2} Posts 
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. 
20200719, 21:44  #391 
"Carlos Pinho"
Oct 2011
Milton Keynes, UK
5^{2}·191 Posts 
How do I run these sieve files under LLR? Client is saying invalid ABC format.

20200720, 03:24  #392 
"Mark"
Apr 2003
Between here and the
1011101111010_{2} Posts 

20200723, 17:36  #393 
"Norbert"
Jul 2014
Budapest
2·7^{2} Posts 
Another new PRP:
1316^28233+28233^1316, 88066 digits. 
20200723, 22:48  #394  
Sep 2010
Weston, Ontario
B6_{16} Posts 
Quote:
And I have now finished doublechecking my initial pfgw finds for interval #9 and everything is fine. So I have added back indices #1568  #1621 to my list. 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 doublecheck of the initial third of interval #10 and the secondhalf 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 reexamine 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 date 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 subinterval is the creation date/time for the log file itself which may be had by doing a getinfo 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. 

20200724, 01:25  #395 
"Mark"
Apr 2003
Between here and the
2×5×601 Posts 
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. 
20200806, 12:31  #396  
Sep 2010
Weston, Ontario
266_{8} Posts 
Quote:
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 my list 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 largestLeylandprimehunt 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. 

Thread Tools  
Similar Threads  
Thread  Thread Starter  Forum  Replies  Last Post 
Leyland Primes: ECPP proofs  Batalov  XYYXF Project  16  20190804 00:32 
Mersenne Primes p which are in a set of twin primes is finite?  carpetpool  Miscellaneous Math  3  20170810 13:47 
Distribution of Mersenne primes before and after couples of primes found  emily  Math  34  20170716 18:44 
On Leyland Primes  davar55  Puzzles  9  20160315 20:55 
possible primes (real primes & poss.prime products)  troels munkner  Miscellaneous Math  4  20060602 08:35 