Talk:Pierpont primes
Scale back 2nd part?
Do I need to scale back the second part? (Find 250th primes). I don't want to have goals that are mostly unobtainable, If so, what would be a more reasonable number? 150th? 100th? --Thundergnat (talk) 23:55, 18 August 2019 (UTC)
- Hm, I would guess not, since there is a brute force Go version that works quickly. The way I wrote my entry is probably slow in general or slow for my language. I saw it done with prime factorizations on OEIS and thought it looked elegant. I'll give a different method a shot when I get to it. --Chunes (talk) 00:27, 19 August 2019 (UTC)
- It is very likely going to be much more efficient to generate Pierpont numbers and check if they are prime than to generate primes and check if they are Pierponts. --Thundergnat (talk) 01:20, 19 August 2019 (UTC)
- Essentially, this isn't going to help comparing (one of Rosetta Code's objectives) computer programming code, in this case, to find/display ginormous (Pierpont) primes, --- unless one has a robust isPrime function (mostly likely a BIF). There is nothing to learn about using an isPrime BIF. Otherwise, it's just an exercise in
wastingconsuming electric power. Interpretive computer programming languages will have a large/largish obstacle to overcome with a brute force approach. This shouldn't be the hurdle to jump over, just because interpretive languages have that handicap. -- Gerard Schildberger (talk) 05:52, 19 August 2019 (UTC)
- Essentially, this isn't going to help comparing (one of Rosetta Code's objectives) computer programming code, in this case, to find/display ginormous (Pierpont) primes, --- unless one has a robust isPrime function (mostly likely a BIF). There is nothing to learn about using an isPrime BIF. Otherwise, it's just an exercise in
- I don't know; for a very large percentage of the time, choosing the right algorithm makes a much bigger difference to how fast things get done than the execution speed of the underlying language. Yeah, having a good library can make things easier, but it's not everything. Personally, I think it can be very instructive to see how different languages deal with and/or work around difficult problems. Just for my own amusement, I went and re-implemented this using no built-in
factoringprimality testing, and no outside libraries. Uses a modified version of the Miller–Rabin_primality_test#Perl_6 with 100 rounds (which is what the Perl 6 built-in routine uses). It still finishes in around 12 seconds on my system; slower than the ~6 seconds using built-ins and ~1.5 seconds using optimized libraries, but still, not too bad. And to be fair, Perl 6 has been called many thing, but blazin' fast is not usually one of them.
- I don't know; for a very large percentage of the time, choosing the right algorithm makes a much bigger difference to how fast things get done than the execution speed of the underlying language. Yeah, having a good library can make things easier, but it's not everything. Personally, I think it can be very instructive to see how different languages deal with and/or work around difficult problems. Just for my own amusement, I went and re-implemented this using no built-in
- Even in an on-line limited and throttled VM it finishes in (slightly) less than 30 seconds. Try it online! I'm somewhat inclined to let it stand. --Thundergnat (talk) 13:22, 19 August 2019 (UTC)
Final Digits
Looking at the results, I see that there appear to be no Pierpont primes of the second kind ending with 9, but 9 is a relatively common final digit of the Pierpont numbers of the first kind. The distribution of the other possible final digits also appears to differ between them. Maybe showing the numbers of each possible final digit would be interesting. Also, the First kind are clearly more frequent than the second kind. --Tigerofdarkness (talk) 09:48, 19 August 2019 (UTC)
- Though thinking about it, the first kind can never end in 1 and the second kind can vever end in 9... --Tigerofdarkness (talk) 11:32, 19 August 2019 (UTC)