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)

• Do (3,5,11) and (11,3,5) count as distinct? IMO they shouldn't, but that should be clarified in the task. 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. --Pete Lomax (talk) 11:09, 29 March 2021 (UTC)

I just added that stipulation for clarity. Thebigh (talk) 11:29, 29 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)

Certainly 28 billion in 48 minutes (you know who you are) has gone too far, without some better or interesting or clever approach.

[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.]

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. --Pete Lomax (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 :) --PureFox (talk) 16:29, 11 March 2021 (UTC)

The REXX entry made use of an intermediate sum from the get-go.   It essentially cuts the number of additions by half.     The next big speed improvement was just using odd numbers for the search.   I had experimented with the idea of just using primes,   as the REXX code that generates primes builds them in a sequential list.   But it made the code a lot harder to understand, even though it was a bit faster.   As it is, using an associative array instead of an   isPrime   function is very fast   (a simple   if   instead of invoking a function).     -- Gerard Schildberger (talk) 16:43, 11 March 2021 (UTC)