# Talk:Emirp primes

## Upper bound?[edit]

*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[edit]

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)

- 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

- 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)

The *three invokes rule* was *intended* for programmers to have their programs to parse or determine from a user-specified request ─── whether from the command-line interface or even by a control program (such as the/a "main" program) to find the emirps (or a a single) emirp, without resorting to (say) find the first 100,000 primes (which in generating by first knowing that the 10,000^{th} emirp falls within that range of the first 100k primes).

What I expected was that the programs were to examine the "input" specifications/parameters (however obtained) and generate the first **N** emirps based on that input (requirement). This, among other things, would ensure that three different guesstimates or generate-as-you-go prime number generation would be used. True, the three "input" requirements were fixed and stated specifically.

However, to make all program entries consistent, that **N** would be chosen to be twenty. The reasons of course, would be to make the output(s) consistent for comparative reasons when examining the various outputs. Another reason that displaying twenty emirps fit on one line nicely. I was thinking of adding "··· to be displayed on one line", but thought better of it. The intent (and it wasn't explicitly specified) was to make the program utilitarian and allow (multiple) executions of the program, for instance, to show the first 50 emirps, ··· or the first 1,000. ··· Or show all the emirps between 4,000 and 8,000, for instance (there are only 43) ─── and I had thought of that as an additional requirement, counting the number of emirps within a range, but I had thought that some programmers would do that automatically ─── and adding yet another requirement would be the straw that broke the camel's back. (One quality of a computer program that I value is that it be *useful*, that is, it can stand alone on it's own merits in fulfilling a request for some general (or specific, depending on your point of view) request, not just three predefined requests). It was (and is) my thinking that if a program can find the first twenty emirps, why not the first sixty? ··· Or 600? But however, this wasn't the case in reality (as per the requirements, not the actual outputs).

At this time (25-March-2014), all program entries (save one) essentially ignored any (user or console) directives/arguments/parameters/options (whether by command line, a controller program that could invoke the main program, or some other means, possibly even telepathy) to generate a variable number (that is, user specified) of any number of emirps (whether a specific emirp or some number of emirps within a range of values or by rank). The reason, I suspect, is that the requirements weren't specific or detailed enough (and I had thought programmers would go the generic route), but I didn't want to write an unnecessarily long or detailed list of requirements, nor mandate a specific method on how to accomplish it, nor specify how/where/what the controlling directives/arguments/parameters/options would be. That would've made the requirements overly specific and too detailed, a criticism leveled before, and in acceding to that, is this result, and I take full responsibility for all the ··· confusion, not to mention the rebellion.

One situation was that I foresaw (and it happened) was that some programmers would learn *a priori* that the 10,000^{th} emirp (prime) fell within the first 100,000 primes (the 100,000^{th} prime is 1,299,709 ─── making it a pretty good guess after-the-fact), and so then generate 100,000 primes, and then just choose the emirps base on the criteria of the three requirements by just simply choosing which primes met the emirp definition, bypassing the intent completely ─── but still meeting the strict requirements, or in other often used words, followed the letter-of-the-law, but not the spirit.

Beforehand, I saw two methods (based on my limited vision) of the processes to determine (er, ··· guesstimate) the range (say, just using the 3^{rd} requirement as an example) in where the 10,000^{th} emirp lay (as the REXX program entry did), or generate primes on-the-go, which some program entries did (and to their very much-envied credit), which is probably the best, cleanest, and most elegant way to solve the requirements. It has style. (This is the method I wanted to use, but I think the solution would've been too bulky, and I still may enter a 2^{nd} REXX solution, but I digress once again.)

Another program entry examined the *number* of arguments presented (essentially argument fodder), and based on that, directed a program to compute hard-coded arguments to satisfy the (first three) numeric requirements.

Most others hard-coding the ranges and then invoked (possibly the main program as directed) which fulfilled the spirit, if not the intent of the three main (first) requirements. I couldn't fault them for their effort, especially since that the numeric directives of those first three requirements were met, and the generated results were also correct. If anything, I may have underestimated in how programmers would have interpreted the requirements, thinking they would instead program each of the requirement numbers idiomatically, as in the case of the N-queens on an 8x8 chessboard; most programmers choose to assume a NxN chessboard and solve the general case instead of the specific. But I digress. So most program entries ended up with hard-coded numbers or ranges, so fourth fifths of the requirements were met, the most important of which where the first three. The fourth requirement was also met by all program entries, and I only included that requirement (the emirps must be in order) because it is easy to find emirps out-of-order, as in the case of taxi-cab numbers. I feel at this time, it would not be wise to mark all-but-one program entries as *incorrect* (or *needs-review*), since most of them met the majority of the requirements. Reminds me of school, 4 out of 5 gets you a **B** ─── or a **B+** if you used an elegant approach. So, nobody flunked, everybody gets a passing grade. But I digress yet once again. The 5^{th} requirement may seem stupid to some, but it *is* a requirement, and not an unreasonable one. To me, it was very basic and even borders on simplistic. It seemed to be very easy to accommodate, but I was almost astonished on how much vitriol and resistance there was in fulfilling/complying to that easy requirement. Perhaps, in hindsight, I was asking too much. A bridge too far.

So, I think the best recourse is to let it slide and I, hoping for the best, will see some effort by programmers of the already-entered program entries in meeting the last requirement by putting forth their best professional/much-experienced effort, and others to continue in solving the first three (well, four) stated requirements idiomatically and generically as possible. -- Gerard Schildberger (talk) 21:02, 25 March 2014 (UTC)

Naive suggestion: This task requires that the same program, in separate runs, should output the first *i* emirps in numerical order, all the emirps between *j* and *k* inclusive in numerical order and the *n*th emirp, where *i, j, k* and *n* should be taken from the command line, from user input, from a dialog box or from some other mechanism appropriate to the conventional usage of the language of implementation. Suggested values for *i, j, k* and *n* are 20, 7000, 8000 and 10000 respectively.
--Brnikat (talk) 20:32, 11 July 2015 (UTC)

### New task: Extensible prime generator[edit]

I have created a new task whose main aim is to provide a generator of primes without a hard upper limit to the primes it generates.

## Candidates[edit]

Note that prime numbers greater than 7 may not end in 2, 4, 5, 6, or 8. Therefore it is only necessary to generate candidate primes that start with 1, 3 or 7.--Nigel Galloway (talk) 13:42, 26 March 2014 (UTC)

- How does one test to see if 1,763 is prime (assuming that trial division by primes is being used)? -- Gerard Schildberger (talk) 15:30, 26 March 2014 (UTC)

- For the specific number you mention I would use the Sieve of Atkin (to show off) to generate prime numbers up to 41, then test the number by trial division of these primes. More relevant to this task is how would I find all 4 digit emirps. Using the Sieve of Atkin I would generate all primes up to 99. Then test each odd number not ending in 5 in the ranges 1001-1999 (using primes up to 45), 3001-3999(using primes up to 63), 7001-7999(using primes up to 89), and 9001-9999(using primes up to 99). Then for each of these 4 lists of candidates test if the reversed number is in the appropriate other list. For all 5 digit emirps use Atkin to generate all primes up to 361. Then test each odd number not ending in 5 in the ranges 10001-19999 (using primes up to 141), 30001-39999(using primes up to 199), 70001-79999(using primes up to 282), and 90001-99999(using primes up to 316). Then for each of these 4 lists of candidates test if the reversed number is in the appropriate other list. etc, etc, ....--Nigel Galloway (talk) 13:30, 27 March 2014 (UTC)

- It is probably faster not to calculate the list starting with 9 but to test for primeality when a Candidate in the 3 lists starting with 1, 3, or 7 ends in a 9.--Nigel Galloway (talk) 13:51, 27 March 2014 (UTC)
- When counting Emirps, one using trial division could use the fact, that Emirps out of 10..01 to 19..99 are mirrored in 9...1,7....1,3...1 and 1...1.What does this mean. I don't need to test numbers ending with "1" when I count them while testing 1....., so 3.... only needs to test Emirp for last digit element of '3,7,9' after that 7...... need tests only for '7,9', at least 9.... need only test for last digit = 9.That nearly halves the tests needed.

- It is probably faster not to calculate the list starting with 9 but to test for primeality when a Candidate in the 3 lists starting with 1, 3, or 7 ends in a 9.--Nigel Galloway (talk) 13:51, 27 March 2014 (UTC)