Damn I love this! (wouldn't actually want it in a codebase at work without comments but still).
For anyone confused here's the implicit reasoning:
If sieve is [false, false, true, false] then the even number marked by true is the one to pick out.
We can detect this with sieve.count(true) < 2

The neat thing is that the answer to this boolean is the same as the actual value we want to get the position of in the array. If it's true then we're looking for the one true, if not then it's the only false.

Am I understanding this test behaviour correctly on the ruby version?
Expected output from random test: [37476679391174395, 0, 7]
I understand this to mean that the input number was 93747667391174395 and the 9 was moved from the front to the 7th position.
But if we move that 9 to the last position we get a smaller number.

Chrono79, as you say i must be as small as possible. But it also says the same about j with no statement about which should take precedence. In the case of 0, 1 it could also be done as 1, 0 with the same effect (and this would be the simpler way too). I might have misunderstood but it seems for the 0, 1 case to make sense another explicit rule would need to be in the text.

No random tests.

For a kata that stresses performance (and then stresses performance!!! some more), even the existing tests are sorely lacking.

The idea is great, but why not throw a couple ten thousand trains at us?

Very succinct and uses syntax this noob is unfamiliar with. But it doesn't use platformLimit to optimize.

• Doesn't appear to test for integers, rather it tests for numbers of every kind. ZozoFouchtra's answer is one of the few that would pass.

As I understand the kata it does test for integers. See (a1[i] % 1 === 0) in thegsi’s solution. The second test case includes a decimal number and an integer. Please let me know your opinion on this.

• The last test case supplies something that isn't an array. The question says they'll always be arrays.

Good point. I have changed the last test case to an array.

• To encourage good practice it would be better to return in only one datatype i.e. false could be "Liar" and true become "Honest". Javascript allows this mixing of return types unlike other languages but taking advantage of that can lead to a lot of trouble and should be done for a really good reason.

Interesting point and not one that I had given much thought to. I have now changed the Booleans to strings “Right” and “Wrong”.

Oh and if it's going to supply them with example test cases why not do one for "not possible" for the sake of completeness

I deliberately left out incomplete in the test cases to make the kata a little more difficult. I kind of prefer it that way!

Oh and if it's going to supply them with example test cases why not do one for "not possible" for the sake of completeness

Nice little problem for teaching fundamentals and well explained.
Some feedback/questions:

• Doesn't appear to test for integers, rather it tests for numbers of every kind. ZozoFouchtra's answer is one of the few that would pass
• The last test case supplies something that isn't an array. The question says they'll always be arrays.
• To encourage good practice it would be better to return in only one datatype i.e. false could be "Liar" and true become "Honest". Javascript allows this mixing of return types unlike other languages but taking advantage of that can lead to a lot of trouble and should be done for a really good reason.