Talk:Strange unique prime triplets

uniqueness of the prime numbers being added

How about:     3 + 3 + 11

Nothing was mentioned about   n,  m,   and   p   being unique or not.     -- Gerard Schildberger (talk) 11:05, 10 March 2021 (UTC)

Added the uniqueness. I would like to rename it "strange unique prime triplets" or some such? --Paddy3118 (talk) 11:33, 10 March 2021 (UTC)

The renaming sounds good to me.     -- Gerard Schildberger (talk) 13:29, 10 March 2021 (UTC)

other definitions of strange primes

Note that there are other definitions of   strange   primes.

One possibility is to rename this Rosetta Code task to:     three primes summing to a prime     or
three unique primes summing to a prime,     or somesuch.

Mathoverflow   has different definition at:

  strange and non strange prime numbers are there infinitely many of them.           -- Gerard Schildberger (talk) 11:28, 10 March 2021 (UTC)

added a stretch goal

I added a stretch goal of finding all the three unique primes summing to a prime, with the primes   <   1,000.

I tried   10,000,   but that seemed to be pushing it a bit too far   (but still doable).     -- 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). --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 :) --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? --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 --Paddy3118 (talk) 13:07, 11 March 2021 (UTC)

Extending the limit based on one's own favorite computer programming language   (or any one specific language)   timings shouldn't be the criteria for a stretch goal.   There are slower computer programming languages that wouldn't attempt a run of that size.   The reason for this site is to compare (among other things)   programming language constructs, algorithms, idioms, methods, etc,   without having a contest to see how many numbers can be generated/produced in the shortest amount of time.   I'd like to see less of how fast a certain computer programming language can execute/compute the results   (for a stretch goal or whatever).   I don't mind viewing the comparison of how fast dissimilar algorithms/methods are when using the same particular computer language   (method A is 50% faster than method B).   That being said, if it were me entering this Rosetta Code (draft) task,   I would've added the stretch goal as part of the task's requirements as a "regular" requirement,   and added a stretch goal of  10,000.   That would've allowed "slower" computer programming languages to try to attempt the stretch goal if feasible,   but still show how their programming language would tackle the goal of  1,000.   Adding a stretch goal made it optional,   noting that there were already existing solutions by the time I added the stretch goal,   and very few of us (I think) don't appreciate moving targets for Rosetta Code tasks,   draft or otherwise.     -- 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. --PureFox (talk) 14:04, 11 March 2021 (UTC)