Anonymous user
Talk:Emirp primes: Difference between revisions
m
→reason for 3 invokes: highlighted a function name.
m (→reason for 3 invokes: removed an errant paragraph break.) |
m (→reason for 3 invokes: highlighted a function name.) |
||
Line 15:
::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.[[User:Bearophile|bearophile]] ([[User talk: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<sup>st</sup> 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. -- [[User:Gerard Schildberger|Gerard Schildberger]] ([[User talk:Gerard Schildberger|talk]]) 00:09, 25 March 2014 (UTC)
| |||