Talk:Lucky and even lucky numbers

Wrong example of even luckies?

take a list of all the positive even integers

2, 4, 6, 8, 10, ...

remove every 2nd number

2, 6, 10, ...

take the 2nd number (which is 4 )

Not 6?

(Also, why was this talk page deleted?) --Ledrug (talk) 09:09, 9 March 2014 (UTC)

I had a question that wasn't relevant once I understood the task more so deleted it almost immediately. --Paddy3118 (talk) 11:50, 9 March 2014 (UTC)

The sequence itself is correct, according OEIS, so the problem is in the description of the task. I believe the 2nd line in the second section is a copy/paste difficulty stemming from how the first sequence is defined. If instead of talking about deleting every other one, I suspect both sequences should be leave out the 2nd "skip every other one", and revise the first rule to be in terms of the odd numbers, the second sequence in terms of the even numbers. So we'd simply have:

Lucky numbers are positive integers that are formed by:

• take a list of all the positive odd integers
• take the 2^nd number   (which is   3 )
• remove every 3^rd number
• take the 3^rd number   (which is   7 )
• remove every 7^th number
• take the 4^th number   (which is   9 )
• remove every 9^th number
• take the 5^th number   (which is   13 )
• remove every 13^th number
• take the 6^th number ···

definition of even lucky numbers

Even lucky numbers are positive even integers that are formed by:

• take a list of all the positive even integers
• take the 2^nd number   (which is   4 )
• remove every 4^th number
• take the 3^rd number   (which is   6 )
• remove every 6^th number
• take the 4^th number   (which is   10 )
• remove every 10^th number
• take the 5^th number   (which is   12 )
• remove every 12^th number
• take the 6^th number ···

Parallelizing these descriptions shows how they are essentially the same algorithm (as shown by the parameterization of the algorithm in the Perl 6 solution). --TimToady (talk) 01:56, 10 March 2014 (UTC)

What does "Mixed case should be supported" mean?

This phrase can be read in diametrically opposite ways. I took it to mean that it doesn't matter what case you type the argument, which means the prior rule about spelling would only care if you had the wrong letters, not the wrong case. By this interpretation the Perl 6 entry is not incorrect in its argument handling, and the example is merely demonstrating case insensitivity. If this is not the intended meaning of "mixed case", it needs to be clarified in terms of case sensitivity vs insensitivity. Perhaps my intepretation is colored by my absolute loathing of "camel case" words, which I think have no place in a task such as this, if indeed they are being considered mandatory. It's quite challenging enough to meet the numeric challenges of this task without all the extra API folderol, in my estimation. --TimToady (talk) 01:09, 10 March 2014 (UTC)

(Also, if the quibble is that Perl 6 entry isn't following the first three rules, it is. It is, in fact, testing for those conditions with the signature matching. If the intent is to mandate some kind of particular error message in response to those errors, it should be made clearer just how anally the original implementation is to be copied.) --TimToady (talk) 01:24, 10 March 2014 (UTC)

(Or if the requirement is for a placeholder comma, it's certainly not necessary for the Perl 6 solution, though I could certainly make it throw one away easily enough. The point of Rosettacode is to show idiomatic usages, not force every language to show how it supports the limitations of other languages...) --TimToady (talk) 01:42, 10 March 2014 (UTC)

Should this task be split?

The more I think about it, the more this seems like two completely distinct tasks unnaturally wedded. We have on the one hand the relatively pretty matter of producing the integer sequences named in the title of the task, and on the other hand, we have the task of implementing a relatively ugly (from a Unix perspective) command-line API. The two tasks seem to have almost nothing to do with each other, and the latter task in not something the title of the page would lead one to expect. It feels like an add-on to me. I'd recommend that we have a page for the pure math, and a different page for the API style, justifiable perhaps as a demo of how to fit into a culture that doesn't use switches for optional arguments. --TimToady (talk) 02:30, 10 March 2014 (UTC)