Anonymous user
Talk:Emirp primes: Difference between revisions
→reason for 3 invokes: not very good reason
m (→reason for 3 invokes: highlighted a function name.) |
(→reason for 3 invokes: not very good reason) |
||
Line 16:
:::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)
:::: 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. --[[User:Ledrug|Ledrug]] ([[User talk:Ledrug|talk]]) 04:12, 25 March 2014 (UTC)
| |||