I've expanded the description if it helps. It feels too elaborate, so you're welcome to trim it down.

I have renamed 2 of the categories to match them with algebraic groups as with the other categories. The change to the test code is backwards compatible. If you see 'N' or 'M' in solutions, these map to 'C1' and 'D1'.

So apparently View Solution clears any reply being written. That's fun.

I had a difficult time getting my solution to pass consistently. To do so, the test cases have to scramble the input several times and then choose the "most random". This does make some sense, actually, but there's a confession buried in there. Which input is scrambled best depends on how you measure, and it's no coincidence that my heuristic matches the testing code exactly, which feels an aweful lot like cheating. I had thought my approach was very plain and others would be able to beat the kata by checking more clever conditions, but computationlan also reports that his solution only passes half the time, much like yours. His approach is slightly different, but I think it's exactly the right kind of solution, and I would in fact like to see it pass consistently.

So I'm very open to changing the test cases to, first of all, select the more random input based on a broader heuristic, and then to build in some leniency. I was actually thinking something along the lines you spelled out, except the tests don't have to pass or fail immediately after the requisite batch. They can be in a grey area and keep testing just to make sure they don't fail. This should help discriminate some of the edge cases more cleanly. A solution that usually fails might reach the grey area by chance, but it's not likely to stay there. A solution that usually passes might fall into the grey area on accident, but it's not likely to fail.

As to languages, I don't feel there's much point to randomizing their order since the script is immediatly apparent from the input string anyway. However, if there were several languages using the same script, probably just the Latin/Roman we're most familiar with, then I agree this could be a better test. You're not going to get the same stop words or other such hacks in English as in German, Gaelic, Turkish, Tagalog, Africaans, Swahili, or any of the romance languages.

Fixed by altering one of the examples.

Interesting. The kata was originally written with precise calculations in mind, but I wonder if it would make more sense to just avoid testing cases like this.

I do wonder if the ranking should be higher, maybe not 4 kyu but at least 5, due to the reasoning that must be done to reverse the process. It's not just like going from A to B. It's not like the instructions explicitly say how to perform the task. And the reasoning isn't just abstract, it's more akin to reverse engineering and so rooted in code.

The latter. I've (partly) clarified this in the description now.

Yes, it's meant to work for that one example only. I've made the initial solution closer in line to avoid confusion, and implemented your suggestion about sectioning.

But I can substitute a different solution, no? If anyone is bold enough to do so, I think it would be for the better.

Derp, sorry. I think I make too many edits. Commented below that I'm OK with brute force on this one. But that wasn't the goal, so when I iterate on the idea, that will be the first priority.

OK at some point I'll revisit this in a new kata. I've resolved to keep this one as is.

I didn't call these out explicitly, but in the description I've touched on other operations.

I must have unpublished it while you were still working on it. I've published again if that helps, but I'll have to revise some of the descrpition.

Interesting, yes. No, it doesn't like. That's not a basic operation. I've never seen it on a blackboard, is another way to say it.

As to brute force, I'm OK with one kata to do that, but see below investigating other ideas.

OK thanks for the response. I wasn't trying to cause confusion. Will standardize.