Anonymous user
Talk:Emirp primes: Difference between revisions
→reason for 3 invokes: not marking entries as incorrect.
(→reason for 3 invokes: (Gulp)!) |
(→reason for 3 invokes: not marking entries as incorrect.) |
||
Line 23:
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). --[[User:Paddy3118|Paddy3118]] ([[User talk: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<sup>th</sup> 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<sup>th</sup> emirp (prime) fell within the first 100,000 primes (the 100,000<sup>th</sup> 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<sup>rd</sup> requirement as an example) in where the 10,000<sup>th</sup> 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<sup>nd</sup> 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<sup>th</sup> 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. -- [[User:Gerard Schildberger|Gerard Schildberger]] ([[User talk:Gerard Schildberger|talk]]) 21:02, 25 March 2014 (UTC)
-----
| |||