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. 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.bearophile (talk)

The C entry's programmer apparently chose an unnecessarily hairy way (repeating what you said, and I don't like to characterize its choice using those words) to implement how to determine which particular task requirement to solve (apparently, by counting the number of arguments specified and use that as a deterministic switch).   The point of this entry was to solve three tasks (a set of the 1^st 20 emirp numbers which was to be specified at invocation time), a set of emirp numbers between two values (inclusive), specified in the same manner, and a specific (high) emirp number, also specified in like manner.   Instead of getting the range of numbers, it used the number of arguments to make a determination of what to produce, from a fixed set of paramaters (as I understand the C code, and that is stretching the use of that word, understand).   Calculating the emirps is rather easy (I thought), although there is much room for optimization, albeit the process could be rather CPU intensive, depending on how the emirps were generated.   I thought the use of the isPrime function a slower way to go --- but it works.   The simpler parts of the task requirements is parsing the command line (or invocation parameters) to determine which emirps are to be generated.   This is not a difficult task.   Whether it is like (or not) other Rosetta Code tasks isn't the issue.   This task was designed to use the command line (or invocation parameters) to have the same program generate the appropriate emirp numbers, depending which requirement is being solved.   The tasks are what they are.   If nothing else, it makes programmers take a different approach to solving a task requirement (requirements that don't come from the same mold), I certainly don't want to solve the same tasks in the same manner over and over again, and I hope others don't as well.   That one particular Rosetta Code entry chose to use an unnecessarily hairy method isn't a reason to dumb the task down.   If the task is too difficult, perhaps someone else can solve it in a easy way.   Also, if one approach isn't viable, then maybe some of us can learn from that (perhaps wrong) approach to solving the task. -- Gerard Schildberger (talk) 00:09, 25 March 2014 (UTC)

I wrote the C code, and you don't have to be so condescending, thank you very much. The C "commandline parsing" is an intentional joke, and silly it may be, there's nothing "hairy" about it. I chose not to parse the args, not because that requirement is difficult, but because it's stupid. Obviously you like commandline args, but there's no reason to make all your tasks "designed to use the command line", it only clutters and distracts. And not every language can be comfortably run with commandline args: Visual whatever language on Windows tend to get parameters from dialog boxes, JavaScript embedded in HTML don't get a commandline, PostScript don't get a commandline, and I'm sure there are more. You want to see how programs deal with different ranges, tell people to deal with different ranges, don't make silly commandments like "Invoke the (same) program once per task requirement". We don't all use REXX and in the way you use it, you know. --Ledrug (talk) 04:12, 25 March 2014 (UTC)

Hi Gerard, I too don't like the requirement of providing a command-line interface but I need to believe that there is a chance that me not wanting it parallels others not wanting to show program output which is something I have always found useful in making it easier to assess examples performance of the task.

So, (gulp), feel free to add an incomplete tag to the Python entry - it does not perform the task (which may well be reasonable to others such as yourself and you are the opposite of an RC newbie). --Paddy3118 (talk) 08:41, 25 March 2014 (UTC)