If you think you need inline assembly for this kata, you are probably using an inefficient method. Micro-optimizing a bad algorithm is usually not worth it; try coming up with a better one instead.

It'll feel good when you beat it though. :)

Someone should rewrite the description of this kata. I see many complaints below pointing out that the algorithm is incompletely specified.

This is what the description should have said:

Choose any two array elements X[i] and X[j] with X[i] > X[j]. Set X[i] = X[i] - X[j].

Repeat until no more subtractions are possible (because all array elements are equal).

It can be shown that whenever there is more than one possible choice of the pair i,j, it doesn't matter which pair you choose: the answer will be the same in the end.

Fixed - a more detailed description of the input is now included.

That's intentional. For this kata, you have to write an entire class from scratch.

Here's the relevant part of the input again. Cells X and Y both have colour 5.

6 6 5 5 5 5
5 5 5 5 5 5
5 5 X Y 5 5
6 6 5 5 5 5
6 6 5 5 5 5
6 6 5 5 5 5

Cell Y has depth 3, but the depth of cell X is only 2 (one step down and one step left get you to a differently-coloured cell). So, X isn't part of the solution.

By "completely trivial" do you mean that the constructors are unnecessary? If so, then yes: they won't be used in most solutions.

The Wikipedia article on OCR-A is fairly detailed. If you want the TrueType font file, it can be downloaded for free from fontzone.com.

The kata doesn't have a built-in way to visualize the images. The idea is that you should code your own visualization; consider it part of the challenge.

Fixed now. Thanks.

Do you still have the solution point you found for this test case? Please post it here if so (3 coordinates, each printed out to 20 decimal places).

My apologies for not responding at the time; sometimes life has to take precedence over Codewars.

Thanks for doing this.

My Optical Character Recognition kata had some discussion of this about 3 years ago.

As for practical Codewars-specific downsides: I actually came across one only yesterday, while changing the R version of this kata. I removed the call to set.seed(), checked that everything still seemed to be working (with different test cases on each submission), and hit "Re-publish" - only to be told that the kata couldn't be published because my solution was failing tests. (Wait, what?) It turned out that the test code itself contained a rarely-occurring bug (arising from the way the sample() function in R behaves differently when its main argument is a vector of length 1). This hadn't been an issue before, because it didn't affect any of the 512 random test cases generated by the fixed random seed I was using. But with a different seed on each submission, you occasionally get test cases that are affected, causing a crash. It was sheer good luck that such a test case was generated by Codewars' (one and only!) final check before publication. If that hadn't happened, then some hapless codewarrior would have had to discover the problem, slowly and painfully realize that the problem wasn't in their own code, get frustrated, raise an issue on the discussion board, etc. - all the stuff that unit testing is supposed to prevent.

Having unpredictable random test cases makes it harder to create good kata that work reliably, because the users will be exposed to test cases that the kata author never used or considered when developing the kata. Often this doesn't cause any problems, but sometimes - as I was reminded yesterday - it does.

Another Codewars-specific problem relates to execution time. With some kata (7x7 Skyscrapers is a good example) randomly-generated test cases can vary widely in required execution time. Big-O is formally defined to be for the worst case, but what Codewars measures is more like the best case, because you can keep re-trying until you get a test set that doesn't include any hard examples. I've certainly had the experience of writing a not-really-good-enough kata solution and getting it to pass anyway by repeatedly hitting "Attempt" until it gets a problem set that it can solve within the required 12 seconds.

There are some compromise solutions. You can have a fixed set of test cases, but present them in an unpredictable random order; this at least makes cheating a bit more difficult. Or you can minimize the number of unpredictable test cases (only a few are really needed to catch the cheaters). It would also help if the Codewars test frameworks all stopped execution after the first failed test, instead of trying all the tests and showing what all the expected answers are.

In the end, I guess it comes down to what the purpose of Codewars is. If it's just to help people learn to program, then perhaps cheating doesn't matter too much and we should emphasize reliable, well-tested, maintainable code. But if the value of 1kyu status goes beyond bragging rights with your friends (if it's helping people get real-world jobs, for example), then it needs to be as difficult as possible to defeat.

Anyway, thanks for your interest. If you have any further thoughts, please post them here.

This is a conversation I've had several times before on Codewars. For software testing in general, unpredictable unit tests are a really bad idea - they lead to bugs that occur only sometimes, unpredictably. Such bugs can be very hard to find and fix. But in an adversarial context like Codewars, something is needed to prevent the adversary easily defeating the system. There are some compromise solutions possible, which I've experimented with in my other kata. But for a simple kata like this one, I'll concede the point and switch to using unpredictable random seeds.

The random tests are generated using a fixed pseudo-random seed, so they are the same every time. This ensures that any bugs in your code will be reproducible.