Talk:Strange unique prime triplets: Difference between revisions

m ((temporarily) forced a TOC.)
 
(16 intermediate revisions by 5 users not shown)
Line 9:
 
:Added the uniqueness. I would like to rename it "strange unique prime triplets" or some such? --[[User:Paddy3118|Paddy3118]] ([[User talk:Paddy3118|talk]]) 11:33, 10 March 2021 (UTC)
 
:: The renaming sounds good to me.     -- [[User:Gerard Schildberger|Gerard Schildberger]] ([[User talk:Gerard Schildberger|talk]]) 13:29, 10 March 2021 (UTC)
 
* Do (3,5,11) and (11,3,5) count as distinct? IMO they shouldn't, but that should be clarified in the task. [[User:Thebigh|Thebigh]] ([[User talk:Thebigh|talk]]) 10:19, 29 March 2021 (UTC)
 
: I just assumed n<m<p was implied, can't see any problem with being specific about that. --[[User:Petelomax|Pete Lomax]] ([[User talk:Petelomax|talk]]) 11:09, 29 March 2021 (UTC)
::I just added that stipulation for clarity. [[User:Thebigh|Thebigh]] ([[User talk:Thebigh|talk]]) 11:29, 29 March 2021 (UTC)
 
== other definitions of '''strange''' primes ==
Line 16 ⟶ 23:
One possibility is to rename this Rosetta Code task to: &nbsp; &nbsp; '''three primes summing to a prime''' &nbsp; &nbsp; or
<br>'''three unique primes summing to a prime''', &nbsp; &nbsp; or somesuch.
 
 
 
'''Mathoverflow''' &nbsp; has different definition at:
Line 28 ⟶ 33:
I added a stretch goal of finding all the three unique primes summing to a prime, with the primes &nbsp; &lt; &nbsp; '''1,000.'''
 
I tried &nbsp; '''10,000,''' &nbsp; but that seemed to be pushing it a bit too far &nbsp; (but still doable). &nbsp; &nbsp; -- [[User:Gerard Schildberger|Gerard Schildberger]] ([[User talk:Gerard Schildberger|talk]]) 13:26, 10 March 2021 (UTC)
 
:Although I don't intend to post it on the main page as it's not part of the task, I coded a second Go version which uses a sieve rather than individual prime calculations and found that there were 74,588,542 unique prime triples under '''10,000''' which sum to a prime. This runs in about 4.3 seconds on my machine (core i7). --[[User:PureFox|PureFox]] ([[User talk:PureFox|talk]]) 15:21, 10 March 2021 (UTC)
 
::Just tried the same thing with Wren and the timing there was a much more sedate 213 seconds. So a higher stretch goal is feasible for the interpreted languages but probably best left where it is :) --[[User:PureFox|PureFox]] ([[User talk:PureFox|talk]]) 15:36, 10 March 2021 (UTC)
 
:::Using a more efficient approach, I've managed to get those timings down to 1.4 seconds (Go) and 30 seconds (Wren). Not as fast as Julia (which probably has a better sieve) but not too bad. Perhaps it would be worth extending the stretch goal to '''10,000''' after all? --[[User:PureFox|PureFox]] ([[User talk:PureFox|talk]]) 10:55, 11 March 2021 (UTC)
 
:::: a run of 10_000 takes <37 secs for the Python code. (I suspect the sieve library may be written in C). I am fine with the 1_000 limit as it stands --[[User:Paddy3118|Paddy3118]] ([[User talk:Paddy3118|talk]]) 13:07, 11 March 2021 (UTC)
 
::::: Extending the limit based on one's own favorite computer programming language &nbsp; (or any one specific language) &nbsp; timings shouldn't be the criteria for a stretch goal. &nbsp; There are slower computer programming languages that wouldn't attempt a run of that size. &nbsp; The reason for this site is to compare (among other things) &nbsp; programming language constructs, algorithms, idioms, methods, etc, &nbsp; without having a contest to see how many numbers can be generated/produced in the shortest amount of time. &nbsp; I'd like to see less of how fast a certain computer programming language can execute/compute the results &nbsp; (for a stretch goal or whatever). &nbsp; I don't mind viewing the comparison of how fast dissimilar algorithms/methods are when using the same particular computer language &nbsp; (method '''A''' is 50% faster than method '''B'''). &nbsp; That being said, if it were me entering this Rosetta Code (draft) task, &nbsp; I would've added the stretch goal as part of the task's requirements as a "regular" requirement, &nbsp; and added a stretch goal of &nbsp;10,000. &nbsp; That would've allowed "slower" computer programming languages to try to attempt the stretch goal if feasible, &nbsp; but still show how their programming language would tackle the goal of &nbsp;1,000. &nbsp; Adding a stretch goal made it optional, &nbsp; noting that there were already existing solutions by the time I added the stretch goal, &nbsp; and very few of us (I think) don't appreciate moving targets for Rosetta Code tasks, &nbsp; draft or otherwise. &nbsp; &nbsp; -- [[User:Gerard Schildberger|Gerard Schildberger]] ([[User talk:Gerard Schildberger|talk]]) 13:24, 11 March 2021 (UTC)
 
::::::Well, I was just using the Go and Wren timings to get some idea of how long it would take for languages of their ilk to complete a higher stretch goal. But, fair enough, let's just leave it at '''1,000'''. --[[User:PureFox|PureFox]] ([[User talk:PureFox|talk]]) 14:04, 11 March 2021 (UTC)
 
::::::Certainly 28 billion in 48 minutes (you know who you are) has gone too far, without some better or interesting or clever approach. <br>
::::::[I take any timings with a big pinch of salt, mostly don't really care that much about 4 or 8x, but certainly want to see any 20 or 100x.]<br>
 
::::::However, I would strongly defend the right of any draft task to be a "moving target" for at least 5 days, besides, no-one is forced to post an entry until things settle down. Otherwise, point taken, I largely agree, elegance beats speed anyday. --[[User:Petelomax|Pete Lomax]] ([[User talk:Petelomax|talk]]) 15:12, 11 March 2021 (UTC)
 
:::::::Thanks for the hint about using an intermediate sum being faster. It doesn't make much difference to Go (down to 1.25 seconds) but it knocks 9 seconds off Wren (down to 21 seconds) so i'm very pleased with that :) --[[User:PureFox|PureFox]] ([[User talk:PureFox|talk]]) 16:29, 11 March 2021 (UTC)
 
:::::::: The REXX entry made use of an intermediate sum from the get-go. &nbsp; It essentially cuts the number of additions by half. &nbsp; &nbsp; The next big speed improvement was just using odd numbers for the search. &nbsp; I had experimented with the idea of just using primes, &nbsp; as the REXX code that generates primes builds them in a sequential list. &nbsp; But it made the code a lot harder to understand, even though it was a bit faster. &nbsp; As it is, using an associative array instead of an &nbsp; '''isPrime''' &nbsp; function is very fast &nbsp; (a simple &nbsp; '''if''' &nbsp; instead of invoking a function). &nbsp; &nbsp; -- [[User:Gerard Schildberger|Gerard Schildberger]] ([[User talk:Gerard Schildberger|talk]]) 16:43, 11 March 2021 (UTC)
781

edits