Reservations for x^y+y^x

rogue · 2020-07-14, 12:48

This thread is to capture reservations and completed ranges per this page. There is another search for primes of this form, but that search is by decimal length not by range of x and y. Those reservations are not managed by this thread.

At this time all y have been tested for all x <= 13000. Note that y < x as we want x^y > y^x.

rogue · 2020-07-14, 12:51

I will reserve all y for 13001 <= x <= 15000. I will also double-check from x=12501 to x = 13000.

I will do all I can to avoid stepping on the toes of the other search for primes of this form less than 100,000 decimal digits. If anything I will be double-checking their work. They will likely complete their search before I start testing the range they are working on.

pxp · 2020-07-14, 17:59

The largest x^y+y^x occurs for y=x which for a given x-range occurs for the largest x in that range. Thus, the largest Leyland number up to x=13000 is 2*13000^13000, which has 53482 decimal digits. Here is a table of Leyland number decimal digits for largest x from 13000 to 30000 at intervals of 1000:

13000 53482
14000 58047
15000 62642
16000 67267
17000 71918
18000 76596
19000 81297
20000 86021
21000 90767
22000 95534
23000 100321
24000 105126
25000 109949
26000 114790
27000 119648
28000 124521
29000 129410
30000 134314

This will give you an idea of where the overlap between the two systems lies. Having checked all Leyland numbers smaller than (currently) 84734 decimal digits implies (barring errors) that I have checked all x smaller than 19728. That allows me to suggest that this table of x, y values (based on Andrey Kulsha's ordering) is complete. Of course it would be nice to have verification.

rogue · 2020-07-14, 18:41

Quote:

Originally Posted by pxp

The largest x^y+y^x occurs for y=x which for a given x-range occurs for the largest x in that range. Thus, the largest Leyland number up to x=13000 is 2*13000^13000, which has 53482 decimal digits. Here is a table of Leyland number decimal digits for largest x from 13000 to 30000 at intervals of 1000:

13000 53482
14000 58047
15000 62642
16000 67267
17000 71918
18000 76596
19000 81297
20000 86021
21000 90767
22000 95534
23000 100321
24000 105126
25000 109949
26000 114790
27000 119648
28000 124521
29000 129410
30000 134314

This will give you an idea of where the overlap between the two systems lies. Having checked all Leyland numbers smaller than (currently) 84734 decimal digits implies (barring errors) that I have checked all x smaller than 19728. That allows me to suggest that this table of x, y values (based on Andrey Kulsha's ordering) is complete. Of course it would be nice to have verification.

Thanks. In the worst case scenario I will be double-checking your work, which shouldn't hurt anyone. I don't expect that to take too long after sieving.

If double-checking reveals no missed primes, then I might forego double-checking for larger x.

rogue · 2020-08-06, 15:16

I've decided to take the doublecheck to x=30000. This will cover y<x for all of t those x. This could be about 6 months of work, but I don't know for certain yet because I need to do a lot of sieving.

To help me with that, I have made changes to xyyxsieve (code is committed, but exe is not on sourceforge yet) to reduce the memory usage of the program. In the previous version, a range of 1000 x can take 8 GB of memory (ouch). The changes have reduced that memory requirement by a factor of 10. Another good result of that change is a boost in speed by about 30%.

rogue · 2020-08-10, 12:57

I have double-checked up to x=13000. All is good.

Sieving for x > 15000 is going much slower than anticipated. With the updates to xyyxsieve, I probably undersieved x <= 15000 by a fair amount. As soon as I finish off other PRP testing I can put more cores against the sieving.

rogue · 2020-08-23, 18:11

I found a bug in xyyxsieve that causes it to remove + terms when p divides the - term. This means weeks of sieving is lost. Fortunately it only means that I need to retest any terms accidentally removed for x < 14000, but I still need to resieve just to find out what I didn't test that should have been tested. On the plus side this only impacts me as the build with this bug is not in the latest distribution of mtsieve.

The bug was introduced when I changed xyyxsieve to support only + or -, but not both concurrently as the older versions support that.

pxp · 2020-08-25, 17:13

Quote:

Originally Posted by rogue

I have made changes to xyyxsieve (code is committed, but exe is not on sourceforge yet) to reduce the memory usage of the program. In the previous version, a range of 1000 x can take 8 GB of memory (ouch). The changes have reduced that memory requirement by a factor of 10. Another good result of that change is a boost in speed by about 30%.

You had previously provided me with an OS X version of this (xyyxsieve.7z). As I am currently entering a phase where I will be sieving millions of large numbers, a 30% boost looks pretty good right now. I had started a sieve to 5e9 on interval #21 back on August 12 and it is currently at 8% with an ETC of mid-January. Ouch!

rogue · 2020-08-25, 21:05

Quote:

Originally Posted by pxp

You had previously provided me with an OS X version of this (xyyxsieve.7z). As I am currently entering a phase where I will be sieving millions of large numbers, a 30% boost looks pretty good right now. I had started a sieve to 5e9 on interval #21 back on August 12 and it is currently at 8% with an ETC of mid-January. Ouch!

How many terms? How many distinct x? How many distinct y?

pxp · 2020-08-26, 00:47

2020-08-12 22:17:06: Sieve started: 3 < p < 5e9 with 7448612 terms (29963 <= x <= 453605, 2 <= y <= 30453) (expecting 7082193 factors). I am currently at p=418504277 with 7114884 factors found.

rogue · 2020-08-26, 02:37

Quote:

Originally Posted by pxp

2020-08-12 22:17:06: Sieve started: 3 < p < 5e9 with 7448612 terms (29963 <= x <= 453605, 2 <= y <= 30453) (expecting 7082193 factors). I am currently at p=418504277 with 7114884 factors found.

With such a large range of x and y, the program I provided is likely faster than the current version that I am running. You can try the attached, but I make no promises that it will be faster. Note that the ABC header format is "ABC $a^$b+$b^$a" or "ABC $a^$b-$b^$a" with no +1 or -1 on each line. I don't recall the format that was supported by what I provided last month.

Note that I am sieving all y < 40000 for x <= 40000.

Also note that it crashes upon shutdown, but that is only after it has written the output file and closed it. I haven't dug into the cause yet. I suspect I'm freeing memory that has not been allocated.

2020-07-14, 12:48	#1
rogue "Mark" Apr 2003 Between here and the 2×3×13×79 Posts	Reservations for x^y+y^x This thread is to capture reservations and completed ranges per this page. There is another search for primes of this form, but that search is by decimal length not by range of x and y. Those reservations are not managed by this thread. At this time all y have been tested for all x <= 13000. Note that y < x as we want x^y > y^x.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Reservations	ET_	Operazione Doppi Mersennes	495	2020-12-19 19:41
Reservations for b^(k*2^n); b = 3, k<750	lukerichards	And now for something completely different	13	2019-05-11 23:27
Reservations	kar_bon	Riesel Prime Data Collecting (k*2^n-1)	129	2016-09-05 09:23
Reservations?	R.D. Silverman	NFS@Home	15	2015-11-29 23:18
4-5M Reservations	paulunderwood	3*2^n-1 Search	15	2008-06-08 03:29

2020-07-14, 12:51	#2
rogue "Mark" Apr 2003 Between here and the 14022₈ Posts	I will reserve all y for 13001 <= x <= 15000. I will also double-check from x=12501 to x = 13000. I will do all I can to avoid stepping on the toes of the other search for primes of this form less than 100,000 decimal digits. If anything I will be double-checking their work. They will likely complete their search before I start testing the range they are working on. Last fiddled with by rogue on 2020-07-14 at 12:56

2020-07-14, 17:59	#3
pxp Sep 2010 Weston, Ontario 2²×47 Posts	The largest x^y+y^x occurs for y=x which for a given x-range occurs for the largest x in that range. Thus, the largest Leyland number up to x=13000 is 2*13000^13000, which has 53482 decimal digits. Here is a table of Leyland number decimal digits for largest x from 13000 to 30000 at intervals of 1000: 13000 53482 14000 58047 15000 62642 16000 67267 17000 71918 18000 76596 19000 81297 20000 86021 21000 90767 22000 95534 23000 100321 24000 105126 25000 109949 26000 114790 27000 119648 28000 124521 29000 129410 30000 134314 This will give you an idea of where the overlap between the two systems lies. Having checked all Leyland numbers smaller than (currently) 84734 decimal digits implies (barring errors) that I have checked all x smaller than 19728. That allows me to suggest that this table of x, y values (based on Andrey Kulsha's ordering) is complete. Of course it would be nice to have verification.

2020-08-06, 15:16	#5
rogue "Mark" Apr 2003 Between here and the 2×3×13×79 Posts	I've decided to take the doublecheck to x=30000. This will cover y<x for all of t those x. This could be about 6 months of work, but I don't know for certain yet because I need to do a lot of sieving. To help me with that, I have made changes to xyyxsieve (code is committed, but exe is not on sourceforge yet) to reduce the memory usage of the program. In the previous version, a range of 1000 x can take 8 GB of memory (ouch). The changes have reduced that memory requirement by a factor of 10. Another good result of that change is a boost in speed by about 30%.

2020-08-10, 12:57	#6
rogue "Mark" Apr 2003 Between here and the 1812₁₆ Posts	I have double-checked up to x=13000. All is good. Sieving for x > 15000 is going much slower than anticipated. With the updates to xyyxsieve, I probably undersieved x <= 15000 by a fair amount. As soon as I finish off other PRP testing I can put more cores against the sieving.

2020-08-23, 18:11	#7
rogue "Mark" Apr 2003 Between here and the 6162₁₀ Posts	I found a bug in xyyxsieve that causes it to remove + terms when p divides the - term. This means weeks of sieving is lost. Fortunately it only means that I need to retest any terms accidentally removed for x < 14000, but I still need to resieve just to find out what I didn't test that should have been tested. On the plus side this only impacts me as the build with this bug is not in the latest distribution of mtsieve. The bug was introduced when I changed xyyxsieve to support only + or -, but not both concurrently as the older versions support that.

2020-08-26, 00:47	#10
pxp Sep 2010 Weston, Ontario 2²·47 Posts	2020-08-12 22:17:06: Sieve started: 3 < p < 5e9 with 7448612 terms (29963 <= x <= 453605, 2 <= y <= 30453) (expecting 7082193 factors). I am currently at p=418504277 with 7114884 factors found.