Small but sweet :)
[Worker #1 Sep 18 17:41:47] 9*10^380734+1 is a probable prime! Wh8: 0976AF3D,00000000 And of course it is proven prime with LLR :) :party: 
This one has not been yet verified but it looks genuine.
6962 · 31[sup]2863120[/sup]  1 4269952 Digits. Largest of the year. Will rank 20 if verified. [url]https://primes.utm.edu/primes/page.php?id=130702[/url] 
Congrats to Ryan Propper for his recent batch of proth mega primes for k = 9, 11 and 13 the largest of which has 3,462,100 digits :smile:

[QUOTE=paulunderwood;539623]Congrats to Ryan Propper for his recent batch of proth mega primes for k = 9, 11 and 13 the largest of which has 3,462,100 digits :smile:[/QUOTE]
What ranges was Propper searching, and did he keep the residues of all the composite candidates he must have covered? This information could be useful to PrimeGrid which is planning to search and doublecheck (at least a part of) these Proth number regions, see [URL="https://www.primegrid.com/stats_div_llr.php"]https://www.primegrid.com/stats_div_llr.php[/URL]. /JeppeSN 
[QUOTE=JeppeSN;539859]What ranges was Propper searching, and did he keep the residues of all the composite candidates he must have covered? This information could be useful to PrimeGrid which is planning to search and doublecheck (at least a part of) these Proth number regions, see [URL="https://www.primegrid.com/stats_div_llr.php"]https://www.primegrid.com/stats_div_llr.php[/URL].
/JeppeSN[/QUOTE] pm ryanp 
New nearrepdigit prime :)
93*10^6422251 :)
[URL]https://primes.utm.edu/primes/page.php?id=130796[/URL] 
[QUOTE=pepi37;540770]93*10^6422251 :)
[URL]https://primes.utm.edu/primes/page.php?id=130796[/URL][/QUOTE] Congrats! 
[QUOTE=paulunderwood;540780]Congrats![/QUOTE]
Thanks! 
[QUOTE=paulunderwood;539623]Congrats to Ryan Propper for his recent batch of proth mega primes for k = 9, 11 and 13 the largest of which has 3,462,100 digits :smile:[/QUOTE]
Go, Ryan, go. The latest is 28th biggest known prime with 3,734,847 digits: [URL="https://primes.utm.edu/primes/page.php?id=130801"] 9*2^12406887+1[/URL] 
[QUOTE=paulunderwood;541322]Go, Ryan, go. The latest is 28th biggest known prime with 3,734,847 digits:
[URL="https://primes.utm.edu/primes/page.php?id=130801"] 9*2^12406887+1[/URL][/QUOTE] There is already a newer and bigger one, [URL="https://primes.utm.edu/primes/page.php?id=130806"]9*2^13334487 + 1[/URL]. He has found 9 huge Proth primes with k in { 9, 11, 13 } in the month of March. Ryan Propper does not respond to private messages. /JeppeSN 
NOT YET VERIFIED
The largest Generalized Fermat of the Year. (and also the largest of the form a^2[SUP]19[/SUP]+1 )
Congratulations to Wolfang and his team. 3638450[SUP]524288[/SUP] + 1 3439810 L4591 May 31st 2020 Ranked as 35 of the list. 
The 20th largest known prime has been found by Ryan Propper:
[URL="https://primes.utm.edu/primes/page.php?id=130967"]6*5^6546983 + 1[/URL] :banana: 
Nice and shiny fresh one
[URL]https://primes.utm.edu/primes/page.php?id=130989[/URL] 9 *10^583696 + 1 :) 
This has been my lucky weekend (just yesterday, I found a T5K prime for CRUS):
26*3^1435875+1 may be prime, but N divides 3^((N1)/3))1, restarting with a=5 Time : 1308.400 sec. 26*3^1435875+1 is prime! (685088 decimal digits) Time : 1299.598 sec. 
Congratulations [B]carpetpool[/B]. It's good to see that at least some of the Top 5k contributors are nice people.:smile:
Well done! 
Another lucky hit:
26*3^1700041+1 may be prime, but N divides 3^((N1)/3))1, restarting with a=5 Time : 938.494 sec. 26*3^1700041+1 is prime! (811128 decimal digits) Time : 946.942 sec. 
Largest prime for 2020 (till now)
TO BE VERIFIED
Congratulations to Serge Batalov. Gaussian Mersenne. #20 on the current list. 2[SUP]15317227[/SUP] + 2[SUP]7658614[/SUP] + 1 4,610,945 digits. 
[QUOTE=rudy235;552206]TO BE VERIFIED
Congratulations to Serge Batalov. Gaussian Mersenne. #20 on the current list. 2[SUP]15317227[/SUP] + 2[SUP]7658614[/SUP] + 1 4,610,945 digits.[/QUOTE] Serge never publish prime until he is 101% sure it is prime :) 
[QUOTE=pepi37;552218]Serge never publish prime until he is 101% sure it is prime :)[/QUOTE]
Well, 101 happens to be prime. 
Congrats to Scott Brown for the "321+" prime, [URL="https://primes.utm.edu/primes/page.php?id=131362"]3*2^16408818+1[/URL], which was 6.5 years in the making by PrimeGrid.
:banana: 
Seems a new prime for the [url='https://www.rieselprime.de/ziki/Riesel_problem']Riesel Problem[/url] was found: [url='https://primes.utm.edu/primes/page.php?id=131405']146561*2^112808021[/url] found by PrimeGrid's project currently in verify status.
This is, when proven, almost 3 years after the last found for this problem. 
"P587124"
Congrats to a1call for [URL="https://primes.utm.edu/primes/page.php?id=131431"]this top5000 prime[/URL] of a most unusual construction.
:banana: 
[QUOTE=kar_bon;563554]Seems a new prime for the [url='https://www.rieselprime.de/ziki/Riesel_problem']Riesel Problem[/url] was found: [url='https://primes.utm.edu/primes/page.php?id=131405']146561*2^112808021[/url] found by PrimeGrid's project currently in verify status.
This is, when proven, almost 3 years after the last found for this problem.[/QUOTE] this number is now proven to be prime, now there are 47 Riesel base 2 candidate left. 
[QUOTE=sweety439;564956]this number is now proven to be prime, now there are 47 Riesel base 2 candidate left.[/QUOTE]
No, that page was already updated: there're still 48 kvalues left. 
New 1.43M repdigit prime will appear soon :)
It was time to find something bigger after 5 years searching in this sequence :) 
Good! Congratulations!

[QUOTE=Batalov;565974]Good! Congratulations![/QUOTE]
Thanks! 
[QUOTE=paulunderwood;564951]Congrats to a1call for [URL="https://primes.utm.edu/primes/page.php?id=131431"]this top5000 prime[/URL] of a most unusual construction.
:banana:[/QUOTE] Very interesting, indeed. The prime in question does not appear to be totally random? I have actually constructed large random provable primes before (over 100,000 digits), but none of them were large enough size for Top5000 at the time. This was a few years ago though and I had lost interest at some point. I am also wondering how sieving was done. I've made general purpose programs and scripts for my searches in finding random primes, but they are far too slow at half a million digits compared to more advanced programs like srsieve and multisieve which won't support testing arbitrary numbers. Also, PFGW appears to test some numbers faster than others, like Proth or Riesel numbers, so I could only imagine the extensive work done to find this prime. These primes also might be of interest: [url]https://primes.utm.edu/primes/page.php?id=119933[/url] [url]https://primes.utm.edu/primes/page.php?id=119934[/url] Edit: I did not see Paul's post was about a week ago, for some reason, this caught my attention... 
And now it is official :)
[URL="https://primes.utm.edu/primes/page.php?id=131466"]92*10^14397611 is prime :)[/URL] :victor::victor::victor::victor::victor::victor: 
@carpetpool
The prime has taken months of work for different iterations and I have modified the sieving over time. As per faster PRP tests for some numbers than others of the same size, I believe it's a matter of proximity to repeated squaring which these iterations happen to be. The same behavior can be seen in Pari when calculating Mod (b,p)^(p1) which is much faster if p is close to repeated squares which indicates that the routines have the intelligence to figure out the fastest way of calculating an Exponentiation. As for the sieving, I use my own setup which means it is probably quite inefficient. However it has one thing going for it: There is often the raised subject of how deep to sieve and I generally disagree with the replies. IMHO one should sieve indefinitely and simultaneously as PRP testing. I basically take a range and let lose multiple threads at sieving it using both PRPTestthreads and TFsievingthreads. Any candidate in the queue that is knocked out by TF saves days of upcoming PRP tests. I have a ryzen 9 PC dedicated to this sequence and run my routines in a virtual box which I can pause, snapshot and resume at any time. I am currently looking for the next iteration but things have slowed down to a crawl. It appears that PRP tests are about 8 times slower than the last iteration. ETA Good luck with your next Top5k carpetpool.:smile: 
[QUOTE]IMHO one should sieve indefinitely and simultaneously as PRP testing. I basically take a range and let lose multiple threads at sieving it using both PRPTestthreads and TFsievingthreads. Any candidate in the queue that is knocked out by TF saves days of upcoming PRP tests.[/QUOTE]If the same computer doing the sieving could eliminate candidates faster by using PRP, what's the advantage of sieving? Or vice versa.

Suppose you are testing 10000 candidates with 1M decimal digits each. And each PRP test takes 4 days and you have 10 threads available. Suppose you run PRP tests on 9 of them and trial factoring on the other. In the 1st 4 days anything divisible by small primes will be knocked out by TF. In the next 4 days candidates divisible by larger primes will be knocked out, next 4 days even larger.... Any candidates that are knocked out of the queue at [U]anytime[/U] means you don't have to spend 4 days for a PRP test on them.

In no way did your explanation answer why sieving is better after the point where a prp test eliminates candidates faster than sieve does. If your sieve eliminates a candidate every 6 days, why do you think you're saving 4 days every time you find a factor?
When sieve is faster, sieve on all 10 threads. When prp is faster, prp on all 10 threads. You way may be convenient for you, but it's not an effort to be efficient. 
Suppose you have 2 available threads.
Suppose there are z candidates to test, none of which are prime. Suppose each PRPTest takes 4 days to complete. Suppose running the 2 TFthreads for 4 days would sieve upto some prime x per thread. Suppose y of the candidates have prime factors greater than x. For the sake of the argument let's ignore the time it takes to run the TFtest on all the candidates. the PRP tests alone will take 4y/2 days.  Now suppose you run 1 of the threads for trialfactoring indefinitely which means the candidates upstream the queue will be sieved deeper and deeper than x. The other thread is used for PRPtests It will take you less than 4y days to PRP test all the candidates because some more of the candidates will be knocked out by TF. How much less days is a factor of how large z is. The larger the z, the deeper the TF, the greater cutdown from 4y days. Since there is no known upper bound for z, there is always a z value feasible where PRP tests will take less than 4y/2. That's my 2 cents and that's how I run my setup, but you are welcome to disagree.:smile: 
Couldn't add an ETA.
To make it clearer the 2 scenarios are a bit of apples and oranges comparison. The second scenario sieves less deep in the beginning and more deep towards the end. However its depth has no upper bound unlike the 1st scenario. I hope that makes sense.:smile: 
We understand what you do, so "makes sense" is a pretty low bar. We disagree that it's faster.
Sieve on both threads until it takes longer than 4 days to find a factor. Then prp on both threads. Every candidate is optimally sieved this way, while in your way the first few tests are badly undersieved, and the last few are really badly oversieved. If we both take a range and race on identical hardware, your way comes out slower. But, if you like the triumph of finding a factor, it's just fine to rank speed as not the first priority. Just don't claim it's better! 
321
Congrats to Rudi Tapper and PrimeGrid for the prime [URL="https://primes.utm.edu/primes/page.php?id=131595"]3* 2^16819291  1[/URL] with 5,063,112 decimal digits and top5000 entrance rank of 21.
:banana: 
[QUOTE=a1call;566150]Suppose you are testing 10000 candidates with 1M decimal digits each. And each PRP test takes 4 days and you have 10 threads available. Suppose you run PRP tests on 9 of them and trial factoring on the other. In the 1st 4 days anything divisible by small primes will be knocked out by TF. In the next 4 days candidates divisible by larger primes will be knocked out, next 4 days even larger.... Any candidates that are knocked out of the queue at [U]anytime[/U] means you don't have to spend 4 days for a PRP test on them.[/QUOTE]I only saw this now, sorry. Sounds convincing at first, but why not use 2 out of 10 threads, or 7 or all?
Fundamentally you have two methods to remove a candidate for good, TF or PRP. If one is faster on average, you have the highest average throughput when using that method exclusively. I don't see how it can be different. [QUOTE]Congrats to Rudi Tapper and PrimeGrid for the prime 3* 2^16819291  1 with 5,063,112 decimal digits and top5000 entrance rank of 21.[/QUOTE]After 5 days verifying it was finally added to the list. 
[QUOTE=bur;570120]
Fundamentally you have two methods to remove a candidate for good, TF or PRP. If one is faster on average, you have the highest average throughput when using that method exclusively. I don't see how it can be different. [/QUOTE] By that logic there would be no justification to use more than one method, either TF or PRPTesting on any given range. But that's not the case now, is it? Both methods are used in practice to weed out candidates they are better at sieving. TF for candidates with smaller factors and PRPTesting for the rest, even though one would have to be faster on acreage on the whole set than the other. 
[QUOTE=a1call;570125]By that logic there would be no justification to use more than one method, either TF or PRPTesting on any given range. But that's not the case now, is it?
Both methods are used in practice to weed out candidates they are better at sieving. TF for candidates with smaller factors and PRPTesting for the rest, even though one would have to be faster on acreage on the whole set than the other.[/QUOTE] No, you are fully misunderstanding what he said. If TF is faster, use it exclusively. At some point in your TF efforts, TF is no longer faster, and PRP becomes faster. At that crossover point, use PRP exclusively. This is clearly the most efficient path, yet you wave your hands and use all sorts of words to make yourself feel better that it's not true. 
[QUOTE=a1call;570125]By that logic there would be no justification to use more than one method, either TF or PRPTesting on any given range.[/QUOTE]
That's a fallacy. It would be true if the speed of each method would be constant as you go deeper, but it is not. The TF speed decreases exponentially, it halves with every bitlevel. The speed of PRP decreases slower with the size of the exponent (range, size of the FFT). In a certain point they will cross. As VBCurtis says. By "speed of TF" we mean how fast you can eliminate an exponent, by finding a factor. TF programs seem "much faster", they do many tests in the wallclock time taken by a PRP test, but to find a factor, you need to do many assignments (roughly, equal to the bitlevel, i.e. if you look for 70 bits factors, you will need to test about 70 exponents, to find a factor). If your hardware can test 70 exponents to 70 bits faster than it takes for the same hardware to do a PRP for an exponent of the same size (plus or minus a little change, considering the certification process, error rates, vanity of having a factor as opposite of having a PRP residue, whatever rows your boat), then YOU SHOULD CERTAINLY DO ONLY TF to 70 bits. This is how GIMPS works since its inception, if we make abstraction of the people who only run TF because they want more credit, or they like to have found factors, or (I would say "selfish") people who only run LL/PRP because they want the glory of finding a prime and take George's money. :razz: Most users here will try to help the project most, by optimizing their rate of getting rid of exponents, at front wave, either doing TF or PRP. Of course, the options will wary in time, according with the exponent size at the front level and the bitlevel that has to be trialfactored, you can do PRP today because the bitlevels are very deep here, and TF next month if your exponent gets higher and the bitlevel is lower or stays the same, but once the exponent and bitlevel is given, and [U]assuming you know your hardware[/U], you should optimally chose ONE of them, and DO THAT ONE ONLY. 
Congrats to Serge Batalov for the smallest known 1 million digit prime:
[URL="https://primes.utm.edu/primes/page.php?id=131964"]10^999999 + 308267*10^292000 + 1[/URL] Can this be limboed? 
[QUOTE=paulunderwood;571995]Congrats to Serge Batalov for the smallest known 1 million digit prime:
[URL="https://primes.utm.edu/primes/page.php?id=131964"]10^999999 + 308267*10^292000 + 1[/URL] Can this be limboed?[/QUOTE] This beats an idea of simply doing 10^999999 + k*10^(333333m) ± 1 with m very small. Such a prime would be simpler to test than Serge Batalov's, but not quite as close to 10^999999. /JeppeSN 
[QUOTE=paulunderwood;571995]Congrats to Serge Batalov for the smallest known 1 million digit prime:
[URL="https://primes.utm.edu/primes/page.php?id=131964"]10^999999 + 308267*10^292000 + 1[/URL] Can this be limboed?[/QUOTE] The smallest known 1 million digit [STRIKE]prime[/STRIKE] is 10^999999+593499 
[QUOTE=sweety439;572046]The smallest known 1 million digit prime is 10^999999+593499[/QUOTE]
That may be the smallest PRP. No proof of primality, unless you have a new theorem :smile: 
DRUG is PRP top
We had a nice email from Jeff Gilchrist this morning saying one of his computers had reported:
[CODE]2^1338029827 is base 3Fermat PRP! (4027872 decimal digits) Time : 9677.550 sec. 2^1338029827 is Fermat, Lucas and Frobenius PRP! (P = 5, Q = 5, D = 5) Time : 75222.576 sec. [/CODE] We would like to thank rouge for his sieve and Jean and George for their software. :banana: :banana: :banana: :banana: It is [URL="http://www.primenumbers.net/prptop/prptop.php?page=1"]official now[/URL] 
A new [URL="https://primes.utm.edu/primes/page.php?id=132142"]Generalized Cullen number[/URL]  4'143'644 decimal digits.

[QUOTE=Batalov;573447]A new [URL="https://primes.utm.edu/primes/page.php?id=132142"]Generalized Cullen number[/URL]  4'143'644 decimal digits.[/QUOTE]
:bow: 
DRUG is PRP 2nd top now :wink:
[QUOTE=paulunderwood;572866]We had a nice email from Jeff Gilchrist this morning saying one of his computers had reported:
[C]2^1338029827 is base 3Fermat PRP! (4027872 decimal digits) Time : 9677.550 sec.[/c][/QUOTE] Sorry, Paul, [URL="https://mersenneforum.org/showthread.php?t=26719"]the top is now retaken [/URL] 
[QUOTE=Batalov;576287]Sorry, Paul, [URL="https://mersenneforum.org/showthread.php?t=26719"]the top is now retaken
[/URL][/QUOTE] The repdigit is an admirable find. 
Riesel problem
After years of work from [url='https://www.rieselprime.de/ziki/Riesel_Sieve']RieselSieve[/url] and further testing/sieving/double checking by PrimeGrid there are currently [url='http://www.prothsearch.com/rieselprob.html']44 kvalues[/url] left for which no prime k*2^n1 was found yet.
After three primes found by Ryan Propper this year for the [url='https://www.rieselprime.de/ziki/Riesel_problem']Riesel problem[/url] and a [url='https://www.primegrid.com/forum_thread.php?id=9624&nowrap=true#149296']post[/url] from him at the PG forum, which says he's "doing some solo hunting" work for 12M<=n<=15M (but not explicitly given which kvalues), PrimeGrid seems stopped the search for those 3 found kvalues according to their [url='https://www.primegrid.com/stats_trp_llr.php']status page[/url] showing they stopped checking at n~11.5M. So this will leave a range of uncertainty if there eventually exists a smaller prime than those found ones. Open questions:  Will PG check the missing ranges?  Is Ryan Propper testing further ranges/kvalues? If so, which ones? Before this is cleared, the Riesel problem still stay at 47 open kvalues left to prove the problem and I think neither Wilfrid Keller nor any serious prime hunter will rest until this inconsistency is resolved. To all: please comunicate your search and make them available to avoid duplicate work. 
[QUOTE=kar_bon;579200]Before this is cleared, the Riesel problem still stay at [B]47[/B] open kvalues left to prove the problem ...[/QUOTE]
I don't have a dog in this game. To be clear. But a simple question arises  can these three k values be [URL="https://en.wikipedia.org/wiki/Riesel_number"]Riesel numbers[/URL]? [I]They cannot.[/I] Then why is it relevant how big the witness primes are? Does this conjecture need [B]two [/B]witness primes  i.e. these known ones, and the slightly smaller ones? [I]It does not.[/I] Am I missing something? 
[QUOTE=kar_bon;579200]Before this is cleared, the Riesel problem still stay at 47 open kvalues left to prove the problem and I think neither Wilfrid Keller nor any serious prime hunter will rest until this inconsistency is resolved.[/QUOTE]
These are both your opinions, and the former is clearly false. 
[QUOTE=kar_bon;579200]Before this is cleared, the Riesel problem still stay at 47 open kvalues left to prove the problem and I think neither Wilfrid Keller nor any serious prime hunter will rest until this inconsistency is resolved.[/QUOTE]
The Riesel problem, by definition, is proving whether 509,203 is the smallest Riesel number. These 3 [I]k[/I]'s, with prime [I]n[/I]'s now known, are no longer relevant for that problem. They cannot be the smallest Riesel number. While it would be useful to know the smallest primes for each [I]k[/I], this is not directly related to the Riesel problem as defined. There are 44 [I]k[/I]'s left in the Riesel problem, corresponding to the 44 Riesel [I]k[/I]'s less than 509,203 with no primes known. 
I've updated the [url='https://www.rieselprime.de/ziki/Riesel_problem']Wiki page[/url] with those notPGfoundprimes, unreserved them, so no longer listed in their [url='https://www.rieselprime.de/ziki/PrimeGrid_Riesel_Problem']project page[/url], but still left a note for those 3 kvalues.
Sure the Riesel problem is to find any nvalue of any of the remianing kvalues to prove the conjecture. But from beginning the project every real primesearcher like Keller or Gallot were anxious to know the lowest nvalue. This also prevents to fill in the missing value for k=2293 in this [url='http://oeis.org/A108129']OEIS sequence[/url], because this lists only the lowest n. Because I could not determine the date when PG stopped the search for those values, I took the 20210501 and the maxn value of the search from their status page. 
[QUOTE=kar_bon;579376]Sure the Riesel problem is to find any nvalue of any of the remianing kvalues to prove the conjecture.
But from beginning the project every real primesearcher like Keller or Gallot were anxious to know the lowest nvalue.[/QUOTE] It does not help your arguments to claim that you are a "real" primesearcher (sp) and others are not, whatever that means. 
I've not claimed me a real primesearcher, but thank you for the title.
I'm collecting data in prime numbers for k*2^n1 (mostly and others, too) for 14 years now (my first page for RPS was in 2007), because there was no data collection in an oversesable form: many small personal projects, some others only testing some ranges, and all data spread around the net. You even don't know how much work I've done over the years and how disappointing it is to see only a prime and no further information like tested ranges. So even if somebody is logged in here, why no further information should be given? In the primesearch community nothing is more annoying to test open ranges to fill some missing data. That's my real concern: to document the whole data to avoid duplicate and disappointing work for others. 
Just wanted to let you know that your efforts are greatly appreciated, kar_bon!

Makoto Morimoto has set a new record for a [URL="https://primes.utm.edu/top20/page.php?id=53"]palindrome prime[/URL] at [URL="https://primes.utm.edu/primes/page.php?id=132591"]490001 digits[/URL], :smile:

Aren't mersenne prime palindromes themselves? :razz:

[QUOTE=LaurV;585155]Aren't mersenne prime palindromes themselves? :razz:[/QUOTE]
I base 2 they are. In fact any n>1 is a palindrome in base n+1 and in base n1 :grin: 
[QUOTE=LaurV;585155]Aren't mersenne prime palindromes themselves? :razz:[/QUOTE]
All primes p not in [URL="https://oeis.org/A016038"]https://oeis.org/A016038[/URL] are palindromes in some base < p1 
Congrats to Serge and Ryan for the two smallest known Mega primes, prove with CHG at 28.7% factored of N+1
[URL="https://primes.utm.edu/primes/page.php?id=132705"]10^999999  1022306*10^287000  1[/URL] [URL="https://primes.utm.edu/primes/page.php?id=132704"]10^999999  1087604*10^287000  1[/URL] :banana: :banana: 
[QUOTE=paulunderwood;587681]Congrats to Serge and Ryan for the two smallest known Mega primes, prove with CHG at 28.7% factored of N+1
[/QUOTE] Two [I]largest [/I]known [I]lessthanMega primes[/I], actually. (The second one was found before search was called off, an incidental finding. :rolleyes: ) [CODE]... 10^999999+308267*10^292000+1 P 1000000 Batalov 02/2021 10^999999+593499 PRP 1000000 Peter Kaiser 02/2013 10^999999 C 1000000  a composite, smallest milliondigit number 10^999999172473 PRP 999999 Patrick De Geest 12/2016 10^9999991022306*10^2870001 P 999999 Propper,Batalov 09/2021 10^9999991087604*10^2870001 P 999999 Propper,Batalov 09/2021 ...[/CODE] 
[QUOTE=LaurV;585155]Aren't mersenne prime palindromes themselves? :razz:[/QUOTE]
Of course all repunits are “palindromes” per se, but in practical terms when a prime is a Mersenne, a Generalized Mersenne ( to other bases ), repunits, generalized repunits, they are not counted as palindromes in the database of “The primePages” 
Congrats to Marc Wiseler and PrimeGrid for the "321" prime [URL="https://primes.utm.edu/primes/page.php?id=132678"]3*2^177480341[/URL] (5,342,692 decimal digits) ranked as the 18th largest known prime.
:banana: :banana: :banana: 
[QUOTE=paulunderwood;587767]Congrats to Marc Wiseler and PrimeGrid for the "321" prime [URL="https://primes.utm.edu/primes/page.php?id=132678"]3*2^177480341[/URL] (5,342,692 decimal digits) ranked as the 18th largest known prime.
:banana: :banana: :banana:[/QUOTE] Big congrats!!!!! 
Another Riesel "other" number is [I]coming soon[/I].
It is a palindrome, chock full of "9"s (with a few others) and is neatly 1,234,567 decimal digits long 
[QUOTE=Batalov;587870]Another Riesel "other" number is [I]coming soon[/I].
It is a palindrome, chock full of "9"s (with a few others) and is neatly 1,234,567 decimal digits long[/QUOTE] I am looking forward to its revelation. The largest palindrome before this one had 490,001 digits. So 1,234,567 digits is quite amazing considering its crunching is done with generic modular reduction. 
[QUOTE=paulunderwood;587879]I am looking forward to its revelation. The largest palindrome before this one had 490,001 digits. So 1,234,567 digits is quite amazing considering its crunching is done with generic modular reduction.[/QUOTE]
[URL="https://primes.utm.edu/primes/status.php"]https://primes.utm.edu/primes/status.php[/URL] id 132704 and 132705 are palindromes. 
[QUOTE=sweety439;587899][URL="https://primes.utm.edu/primes/status.php"]https://primes.utm.edu/primes/status.php[/URL]
id 132704 and 132705 are palindromes.[/QUOTE] No they are not :no: Reversing the digits does not give the same number. [url]https://primes.utm.edu/primes/page.php?id=132715[/url] is a palindrome. Congrats Serge and Ryan. UTM's Prime Pages parser calculated the decimal digits as 1234568 :ermm: 
[QUOTE=paulunderwood;587905]UTM's Prime Pages parser calculated the decimal digits as 1234568 :ermm:[/QUOTE]
Prof.Caldwell's calculator had insufficient precision. I'll drop him a note. It is, of course, 1234567. All palindromes of even length (except 11) are composite! :rolleyes: [SPOILER]Hint: they are divisible by 11[/SPOILER] 
[QUOTE=paulunderwood;587879]I am looking forward to its revelation. The largest palindrome before this one had 490,001 digits. So 1,234,567 digits is quite amazing considering its crunching is done with generic modular reduction.[/QUOTE]
Wow! A megaprime palindrome. And one with more than twice the digits than the previous one! I have to see it to believe it!:philmoore: 
When I was already way into sieving, I thought that I should have picked [C]1234321[/C] decimal digits length :rolleyes:
But it turned out good. With 1234567 digits' dataset the hit came, statistically speaking, [SPOILER]very![/SPOILER] early. So it [URL="https://primes.utm.edu/primes/page.php?id=132715"]was lucky[/URL]. 
The prof has been busy. He fixed the palindrome length and puzzlepeter's arithmetic progression, which comes second on table two of [url]https://primes.utm.edu/top20/page.php?id=14[/url].
Hint: An AP9 could be quite easy to find to make it to the top of table two. For the AP8, I wrote my own GWNUM code which was 15% faster, I think mainly by dropping repetitive evaluations of the primorial coefficient. I'd willing to share it with any interested parties. 
Good! Excellent!
Even Kamadasan wrote to him and cc:'d me (as if I could help :rolleyes: ). But it is fixed now, cool beans. 
[QUOTE=Batalov;587937]When I was already way into sieving, I thought that I should have picked [C]1234321[/C] decimal digits length :rolleyes:
But it turned out good. With 1234567 digits' dataset the hit came, statistically speaking, [SPOILER]very![/SPOILER] early. So it [URL="https://primes.utm.edu/primes/page.php?id=132715"]was lucky[/URL].[/QUOTE] So if it is not secret how many candidates was tested before prime appear? 
[QUOTE=pepi37;588390]So if it is not secret how many candidates was tested before prime appear?[/QUOTE]
About 18,000 of the ~316K inputs that Serge originally sent me. P.S. (S.B.)  the exact row number for the hit was 13,239th 
[QUOTE=ryanp;588395]About 18,000 of the ~316K inputs that Serge originally sent me.
P.S. (S.B.)  the exact row number for the hit was 13,239th[/QUOTE] 13239th: small number of candidates for such prime. Very lucky hit :) 
This is an incredible result! [url]https://primes.utm.edu/primes/page.php?id=132738[/url]
But now we have [B][SIZE="4"]two[/SIZE][/B] different record arithmetic progression of 3 elements of 884,748 and 807,954 digits. the other one being. [URL="https://primes.utm.edu/primes/page.php?id=132738"]https://primes.utm.edu/primes/page.php?id=132738[/URL] Still these AP3 is truly impressive as the number of digits either is over 70% more than the previous one which was 406,437 digits. Congratulations to Ryan and Serge.:bounce wave: 
Congrats to James Winskill for the mega primorial prime: [URL="https://primes.utm.edu/primes/page.php?id=132758"]3267113#  1[/URL] (1,418,398 decimal digits).
:banana: 
[QUOTE=paulunderwood;588860]Congrats to James Winskill for the mega primorial prime: [URL="https://primes.utm.edu/primes/page.php?id=132758"]3267113#  1[/URL] (1,418,398 decimal digits).
:banana:[/QUOTE] Yes, in the last few days we have had two new categories of primes entering the megaprime territory. A [URL="https://en.wikipedia.org/wiki/Palindromic_prime"]Palindromic[/URL] with 1,234,567 digits and this [URL="https://en.wikipedia.org/wiki/Primorial_prime"]Primorial[/URL] with 1,418,398 digits. The next one coming is probably the 3[SUP]rd[/SUP] term of a [URL="https://en.wikipedia.org/wiki/Primes_in_arithmetic_progression"]Prime in A.P. [/URL] We now have close to 1,125 megaprimes 
[QUOTE=rudy235;588876]...A [URL="https://en.wikipedia.org/wiki/Palindromic_prime"]Palindromic[/URL] with 1,234,567 digits and ...[/QUOTE]How about [I]two [/I]of them? :rolleyes:

[QUOTE=Batalov;588934]How about [I]two [/I]of them? :rolleyes:[/QUOTE]
You mean "two more"? [url]https://primes.utm.edu/primes/page.php?id=132766[/url] [url]https://primes.utm.edu/primes/page.php?id=132767[/url] :banana: :banana: 
How difficult is to prove a primorial Prime?
[URL="https://primes.utm.edu/primes/page.php?id=132758"]3267113#  1 [/URL] [B][COLOR="Navy"]Verification status (*): InProcess[/COLOR][/B] Is still unproven. I would think that having the primorial +1 100% factored would make proving it a matter of a couple of says. A week in the worse case. 
[QUOTE=rudy235;590778]How difficult is to prove a primorial Prime?
[URL="https://primes.utm.edu/primes/page.php?id=132758"]3267113#  1 [/URL] [B][COLOR="Navy"]Verification status (*): InProcess[/COLOR][/B] Is still unproven. I would think that having the primorial +1 100% factored would make proving it a matter of a couple of says. A week in the worse case.[/QUOTE] Some numbers require proof attempts at increasing sizes of FFT. 
Two birds with one stone
Congrats tp Ryan and Serge for the record Nearrep Digit / Palindrome prime [URL="https://primes.utm.edu/primes/page.php?id=132851"]10^1888529  10^944264  1[/URL]

[QUOTE=paulunderwood;591030]Congrats tp Ryan and Serge for the record Nearrep Digit / Palindrome prime [URL="https://primes.utm.edu/primes/page.php?id=132851"]10[SUP]1888529[/SUP]  10[SUP]944264[/SUP]  1[/URL][/QUOTE]
Yet another custom sieve for such hybrid beasts: quick sketch: We are searching for NRP(K,n) = 10[SUP]2n+1[/SUP]K*10[SUP]n[/SUP]1. K can only be 1,2,4,5,7,8. (K=3 has algebraic factorization, which is not needed ...because the whole expression is divisible by 3 when 3K). Step 1. Let x=10^n, then NRP(K,n) = 10x[SUP]2[/SUP]Kx1 . I solve this quadratic equation just like in school but x is some Mod(x,p) then sieve by p Step 2. If quadratic equation has solution (nearly half the time; if it doesn't , nothing to sieve out), then  Step 3. Solve 10^n = x[SUB]1[/SUB] and 10^n = x[SUB]2[/SUB]. This is called znlog() and these values will periodically repeat with period znorder(). Step 4. Sieve out and repeat for 7<= p <= 10^11 or 10^12. Step 5: remove special cases for p={7,11,13} (this actually removes a huge fraction of candidates with K=2, that's why [URL="https://stdkmd.net/nrr/9/99799.htm"]it is the "thinnest" K[/URL]) The trick is to code steps 1, 2 and 3, and to know how. Step 6. Test. (we test all six number forms in order of size. The fact that K=1 produced the first hit is accidental. With K=1, the number looks a bit more elegant.) 
[QUOTE=rudy235;590778]How difficult is to prove a primorial Prime?
[URL="https://primes.utm.edu/primes/page.php?id=132758"]3267113#  1 [/URL] [B][COLOR="Navy"]Verification status (*): InProcess[/COLOR][/B] Is still unproven. I would think that having the primorial +1 100% factored would make proving it a matter of a couple of days. A week in the worse case.[/QUOTE] After 20 days (10/17/21) it was proven prime. 
[QUOTE=Batalov;591031]Step 5: remove special cases for p={7,11,13} (this actually removes a huge fraction of candidates with K=2, that's why [URL="https://stdkmd.net/nrr/9/99799.htm"]it is the "thinnest" K[/URL])[/QUOTE]
You mean that the [URL="https://www.rieselprime.de/ziki/Nash_weight"]Nash weight[/URL] (or [URL="https://stdkmd.net/nrr/prime/primedifficulty.txt"]difficulty[/URL]) for K=2 (999...9997999...999) is very low? 
[QUOTE=sweety439;591120]You mean that the [URL="https://www.rieselprime.de/ziki/Nash_weight"]Nash weight[/URL] ...[/QUOTE]
Dare you to define it (for these six sequences), but yes. [QUOTE=sweety439;591120]... (or [URL="https://stdkmd.net/nrr/prime/primedifficulty.txt"]difficulty[/URL]) for K=2 (999...9997999...999) is very low?[/QUOTE] Dare you to define it (for these six sequences), but yes. 
If I may ask how many candidates remain after that ?

2 Attachment(s)
[QUOTE=pepi37;591322]If I may ask how many candidates remain after that ?[/QUOTE]
Sure. 
New Primorial Prime found
Recently a new 1 type primorial prime was found at PRPNet.
[URL="https://primes.utm.edu/primes/page.php?id=132758"]3267113#  1[/URL] It has 1418398 digits, making it the largest known one. The last 1 primorial prime was found more than 9 years ago, so this is quite the finding. The last +1 primorial prime hit is from 2001 btw. 20 years ago. :D I think it's an interesting type of prime due to its involvement in Euclid's proof of the infinitude of primes. Not many people seem to hunt for them though and they seem somewhat scarce taking into account that N+1 has lots of factors. [color=red][B]MODERATOR NOTE:[/b] Moved to this thread, which already has [url=https://www.mersenneforum.org/showpost.php?p=588860&postcount=275]this post[/url] and several followups related to this number.[/color] 
[QUOTE=bur;591379]Recently a new 1 type primorial prime was found at PRPNet.
[URL="https://primes.utm.edu/primes/page.php?id=132758"]3267113#  1[/URL] It has 1418398 digits, making it the largest known one. The last 1 primorial prime was found more than 9 years ago, so this is quite the finding. The last +1 primorial prime hit is from 2001 btw. 20 years ago. :D I think it's an interesting type of prime due to its involvement in Euclid's proof of the infinitude of primes. Not many people seem to hunt for them though and they seem somewhat scarce taking into account that N+1 has lots of factors.[/QUOTE] PRP tests for these are quite quick, compared to proofs. However they need generic modular reduction for Fermat PRP tests, whereas smallk Riesel and Proth prime run 4x (?) faster using a special mod. The rarity of these numbers might put the next beyond the powers of BatalovPropper. [color=red][B]MODERATOR NOTE:[/b] Moved to this thread, which already has [url=https://www.mersenneforum.org/showpost.php?p=588860&postcount=275]this post[/url] and several followups related to this number.[/color] 
Thanks for moving the post.
[QUOTE]The rarity of these numbers might put the next beyond the powers of BatalovPropper.[/QUOTE]Who knows, it's not like where GIMPS is currently at where 20M+ consecutive candidates are composite  at least I don't think so. I always forget the estimate for the digit size of primorials but the FFT size remains very managable even up to 20,000,000# where it's 3M. So if anyone was willing to put some larger ressources towards primorials or factorials, I'm pretty sure it'll yield some nice results before ending up in GIMPS waters. 
[QUOTE=bur;591586]I always forget the estimate for the digit size of primorials but the FFT size remains very managable even up to 20,000,000# where it's 3M.[/QUOTE]The number of decimal digits in p[sub]k[/sub] is roughly p[sub]k[/sub]/ln(10). We have
? 3267113/log(10) %1 = 1418889.1476543787883927627556683863802 As indicated above, 3267113#  1 actually has 1418398 digits. The estimate is a consequence of the Prime Number Theorem, which gives the asymptotic estimate ln(p[sub]k[/sub]#) = ln(2) + ln(3) + ... + ln(p[sub]k[/sub]) ~ p[sub]k[/sub] 
All times are UTC. The time now is 02:47. 
Powered by vBulletin® Version 3.8.11
Copyright ©2000  2023, Jelsoft Enterprises Ltd.