I daresay this is the solution. It is the most succinct and clear transformation of one data shape to another.

nobits? documentation

@adamisom, what's not explained very well here is that you're trying to move from the current population to a new population made up of modified copies from the original one. That's why you're duplicating them (because you may wish to select a member more than once in its original state), and why you need to iterate this step multiple times (to build up the new population to the right size).

Hope that helps, this kata really did feel like fumbling around in the dark for a lot of it.

I would assume that it would be the folks around here that appreciate recursion.
The time to process is probably the fastest of all solutions.
My solution as example had many many more iterations and is much slower.
I think it is a beautiful recursive work of art. I'm sure im not the only one...

Just reading your code and saw nobits? which I have not seen before. Looking at your code I honestly can't make out what's going on. Looking at the ruby docs is not a lot more helpful either. Googling in general is coming up with not much. Woudl you care to explain how nobits works?
Thanks in advance :)

LOL folks that probably equate least lines to "better practice". It is clever for sure though :]

Who on earth voted this Best Practices?

I'm confused by one thing in the problem description: it seems to me that each 'iteration' of altering the population

1. picks two existing chromosomes (with roulette wheel selection)
2. duplicates them (the word 'duplicate' is in the description)
3. for the two new duplicate chromosomes, crossovers (might?) happen (mutation also might happen but is irrelevant to my question)
4. repeat "until you have a new population the same size as the original one."

But how can you have a population the same size if every iteration always increases the population by two?
What am I missing?

Your solution has a high time complexity. If you don't know what that is, now would be a good time to find out, since you're 4kyu.

This is beautiful and would be greatly improved if it was production code with one comment.

Here's why: the code would be broken if at ANY point any of the 'subtraction' tokens came before the un-modified token.

What I mean is: if C was listed in the hash before CM, or I before IV, and so on.

In fact, this code also relies on the fact that Ruby maintains hash order, but that is not strictly guaranteed by MRI. However, in practice I don't think anyone runs into hash order being a problem.

No, my main concern was that there should be a comment to the effect "Make sure subtraction tokens are listed before un-modified tokens (e.g. C before CM, I before IV)".

I think the kata description should specify that it should be able to handle arrays as well as strings.

m is the original input value, in which language do you see it being negative?