Talk:Emirp primes

Upper bound?

Invoke the (same) program once per task requirement, this will show what limit is used as the upper bound for calculating surplus (regular) primes.

I am unsure of the need for the above. Some prime generators are set up to automatically expand to give higher primes until reaching system limits such as this one.

I never thought that any contemporary computer language (and operating system) would exceed system limits on a (I think, reasonable) request for a modest number of primes.   If the prime number generator automatically expands the (list of) primes until it has enough to fulfill what is required, so much the better.   I had assumed that most algorithms would try to calculate an upper bound and then generate as many "regular" primes as required up to that upper bound, and then find the necessary emirp primes from the "regular" primes (list).   Specifically, I was trying to avoid programmers generating 11,237,000 primes, and then solve the task requirements by simply grepping what is needed.   I was hoping for some intelligent choices (assuming that was the mechanism chosen). -- Gerard Schildberger (talk) 08:39, 24 March 2014 (UTC)

reason for 3 invokes

The reasoning behind the requirement to invoke the same computer program three different times (not a subroutine or three different subroutines based on a trigger word) was to allow the specification of argument(s) from the command line (or some other method of invocation) such that the computer program could show:

• any number of emirp primes from 1 to nnn,
• all emirp primes between two values (inclusive),
• a specific emirp prime.

To do so would require parsing the specified numbers (and/or options), determine if a range of values or specific emirp primes were wanted, or if only a specific emirp prime was wanted.   Using a nonsense word to trigger which requirement was to be satisfied wasn't even envisioned.   I'm sorry if that wasn't made clearer, I was trying to keep the wording of the task requirements simple and short, and have the encapsulating computer program make the decisions on how to show desired emirp primes.   Specifying particular numbers just made the comparing of the various outputs much simpler (and consistent). -- Gerard Schildberger (talk) 09:54, 24 March 2014 (UTC)

I'd like this requirement to be removed.

C Entry

The is_prime function in the C entry seems to give a wrong result for the inputs 1 2 3 5 7. The C entry shows that that requirement makes the code unnecessarily hairy. The D entry has a simpler main function, that is more similar to most other Rosettacode Tasks. The point of this entry is to compute Emirp numbers.