mersenneforum.org

mersenneforum.org (https://www.mersenneforum.org/index.php)
-   Conjectures 'R Us (https://www.mersenneforum.org/forumdisplay.php?f=81)
-   -   Bases 251-500 reservations/statuses/primes (https://www.mersenneforum.org/showthread.php?t=12993)

mdettweiler 2010-08-05 16:21

[quote=henryzz;224163]None except the second batch of serp 6 stuff I just posted. There will be some more in the next few days as I am finishing off the riesel bases with CK<100.
If you email me the script I can do the conversion if that would be easier.[/quote]
The script is a mess--it's not really in any condition to send to anyone at this point. A perpetual back-burner project that I've been working on here and there is to re-write the entire conversion suite into one unified program that can be easily distributed and run by anyone. When that's done, I'll post it here for anyone to download.

In the meantime, I don't mind processing results for others as needed--by now I've got a pretty good process figured out so that I can do them quickly (even the conjectures with k's removed partway).

Batalov 2010-08-08 03:29

I guess I want to find a Generalized Fermat, too. :-)
Reserving S406 1-ker to n=100K. (The prime will be a GFN because only even n's are in play here.)

mdettweiler 2010-08-08 03:32

Reserving S288 as new to n=25K.

My reason for picking this base is of some potential mathematical interest: 288 = 18*16 = 18*2^4, which means that this base can actually be converted to base 2. Namely

k*288^n+1 = (k*18^n)*2^4n+1

For more information on these types of conversions (which are handled automatically by LLR), see [url=http://www.mersenneforum.org/showpost.php?p=220008&postcount=18]here[/url]--strangely, Jean seemed to indicate in that post that this trick only worked with bases of the form odd*2^x, but a little calculator fiddling (and tests with LLR 3.8.1) confirmed that the trick works as shown above for base 288, which is 18*2^4 (i.e. even*2^x). Since LLR does indeed recognize this automatically, I'm guessing this was an error on Jean's part.

Batalov 2010-08-08 05:20

[quote=mdettweiler;224426]...288 = 18*16 = 18*2^4...
For more information on these types of conversions (which are handled automatically by LLR), see [URL="http://www.mersenneforum.org/showpost.php?p=220008&postcount=18"]here[/URL]--strangely, Jean seemed to indicate ...[/quote]
18 > 2^4, so that doesn't fit Jean/Zhou's transformation.
However, re-write it this way:
288 = 9*32 = 9*2^5
...and 9 is odd, and 9 < 2^5 and everything works.
[SIZE=1][/SIZE]

mdettweiler 2010-08-08 13:30

[quote=Batalov;224432]18 > 2^4, so that doesn't fit Jean/Zhou's transformation.
However, re-write it this way:
288 = 9*32 = 9*2^5
...and 9 is odd, and 9 < 2^5 and everything works.
[/quote]
Ah, I thought I was missing something, but I dismissed my concerns when I saw that LLR did indeed do the conversion. Now I see how that works. :rolleyes: Thanks for the explanation.

gd_barnes 2010-08-09 23:16

[quote=Batalov;224425]I guess I want to find a Generalized Fermat, too. :-)
Reserving S406 1-ker to n=100K. (The prime will be a GFN because only even n's are in play here.)[/quote]

It is kind of interesting that technically, we DO have k's remaining that can make GFNs. This can create confusion about why we search them. That is:

If we are searching a k/base of the form k^2*b^(2n)+1 [or the more inclusive k^(2^q)*b^(2n)+1] then that is a GFN also. The project shows as not considering GFNs of the form b^q*b^n+1. The reason why is that upon the reduction of this latter form to b^n+1 (the requirement to be a GFN), base b must remain static across all n with the subsequent problem that n must be a power of 2 with little chance for prime.

But:
For a GFN form k^(2^q)*b^(2n)+1 (such as Ian's recent 4*650^96222+1 prime), in order to reduce such a form to b^n+1, the base must be different for each n. For such forms, their k-value should produce primes just as often (or more often) than other k-values.

Example: 4*650^96222+1 = (2*650^48111)^2+1. To reduce to b^n+1, b must be 2*650^48111. Observe how b would be different for each n.

I offer this explanation because it was a small point of confusion of my own about a year into the project when attempting to more generalize the GFNs that should be excluded. Originally I had only excluded b^n+1. I subsequently increased that to include b^q*b^n+1. That came into play the most on base 2 where k=2, 4, 8, 16, etc. are not considered. But there are quite a few recent examples where k=b or k=b^2 have been excluded.

Edit: These GFNs that we are searching can just keep going and going...k^(2^q)*b^(2n)+1 is still not all inclusive of all of them. Any k/n combo of the form k^(m^q)*b^(mn)+1 would also make a GFN. This will come into play most frequently for k=8 on the Sierp side where there are n's being searched that are divisible by 3. For such searches, m=3. To the best of my knowledge, that form generalizes all GFNs that we would consider searching with the project.


Gary

Batalov 2010-08-10 01:31

[quote=gd_barnes;224674]This will come into play most frequently for k=8 on the Sierp side where there are n's being searched that are divisible by 3. For such searches, m=3. [/quote]
No, these will be simply algebraically composite. Cubes are no good. k=4,9,16,25,...,64,81,100 are the ticket to immortality. Why is that?

I was stumped for a moment with the UTM's definition (not that anything is wrong with it). Numbers that fit b[sup]2^n[/sup]+1 where b>1 and n>0 get an official note "Generalized Fermat" there - and get a special archival status. That means that this Ian's number will [I]not[/I] be off the list even after 50 years, when at the bottom of top-5000 will be M49 or whatnot. :rolleyes: Regardless. (Mersenne's of course are also archival.)

Of course, I don't expect the S406 prime (if any) to be distinguished enough for that. And, I agree, these should not be avoided in searches. Simple b[sup]2[/sup]+1 (with a [I]b[/I] very large) should not be very rare.

[COLOR=green]EDIT: The only thing special about b[sup]2[/sup]+1 is that its divisors will have to be k*2[sup]2[/sup]+1; and if we have any b[sup]4[/sup]+1, their divisors will have to be k*2[sup]3[/sup]+1. We can sieve a bit faster/higher.[/COLOR]

Batalov 2010-08-10 01:36

S343 is finished to 75K. No extra primes (2 already reported). Started with 9[I] k[/I]; now, 7 [I]k[/I] remain. Results emailed. Base released.

gd_barnes 2010-08-10 04:35

[quote=Batalov;224694]No, these will be simply algebraically composite. Cubes are no good. k=4,9,16,25,...,64,81,100 are the ticket to immortality. Why is that?
[/quote]


As Ian would say: Brain fart. lol Of course any k^3*b^(3n)+1 is always algebraic. Yes, agreed, all k=4, 9, 16, etc. are the ticket to immortality for GFNs on the Sierp side. Why? Because they are perfect squares and so make GFNs when n is even.

I should have stopped while I was ahead. :-)

I had a feeling that you would review my math. Thanks for doing that.

I think you may be mistaken about those archival forms at the top-5000 site. (Or maybe I'm misunderstanding your intent.) Although any primes in the top-5000 that are GFNs are stated as such, only the top 20 GFNs are listed somewhere. At 49th place, Ian's is not in a separate GFN listing because it's not in the top 20. In other words, they are no longer anywhere (or otherwise "counted" as someone's total primes) once the prime itself is > 5000th place. Ian's prime will no longer be counted likely after < 5 years because it will be > 5000th place. The fact that it is a GFN makes no difference.

Batalov 2010-08-10 04:44

All true ...but I still want one. :devil:

Interesting b[SUP]8[/SUP]+1 / b[SUP]4[/SUP]+1 chain is 256*319^n+1 (half and half of each); and 16*248^n+1 is a b[SUP]4[/SUP]+1. No reservation, just a curio. Sieving (with a jailbroken sr1sieve; put return 2 or 3 in gen_fermat_y()) is just a tad faster than usual. So, the savings are not that big. Nothing to see here people! Move along, move along...
:leaving:

gd_barnes 2010-08-10 05:02

[quote=Batalov;224703]All true ...but I still want one. :devil:

Interesting b[sup]8[/sup]+1 / b[sup]4[/sup]+1 chain is 256*319^n+1 (half and half of each); and 16*248^n+1 is a b[sup]4[/sup]+1. No reservation, just a curio. Sieving (with a jailbroken sr1sieve; put return 2 or 3 in gen_fermat_y()) is just a tad faster than usual. So, the savings are not that big. Nothing to see here people! Move along, move along...
:leaving:[/quote]

16*248^n+1 is only b^4+1 when n is divisible by 4 although is a GFN when n is divisible by 2.

Along those lines, you are aware that any 4*b^4+1 are always algebraic. Correct? That came up in another thread and is part of the reason why k=4 is somewhat difficult to find a prime for on the Sierp side. (i.e. 4*b^(4n)+1 is algebraic) So for k=4, you can delete any n's remaining in the sieve that are divisible by 4. These are far from obvious because sr(x)sieve would not remove them automatically nor would it give it's usual "warning: xxxx contains algebraic factors" message. For the same reason, k=4 is completely eliminated from testing on S625 because all n's would be algebraic; although that base has not been reserved at this point.


Gary


All times are UTC. The time now is 23:02.

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