I'd like to point out that dividing by 3 is not the correct way to convert RGB to grayscale, and maybe it's best if it accepts a 2d array of singular grey values instead.

Test output is currently absolutely disgusting because at least it was better than the unintelligible mess that was the old one.

Raising this issue so that people can yell at me if I don't fix it eventually.

The description states that the input should be an NxM array, but the random tests for Python can produce arrays with rows of differing lengths.

java translation (author inactive)

Very similar to this kata

You use nested "it" blocks in JS tests.

This one sample test is not enough for users to figure out what to do. I'm passing the sample test, but fail on every random test. I find this recursive behavior explanation very fishy. It seems that depending on the order of recursion, other results can be provided. Or should we be able to reiterate existing pixels in case we can make new progress? This spec is very unclear to me.

C Translation (author inactive).

C translation (author inactive)

Python translation: https://www.codewars.com/kumite/63f1296761aa3b0e4e749751?sel=63f1296761aa3b0e4e749751

JavaScript initial code is using bad style by extending the prototype enumerably with String.prototype. = .... Initial code should use Object.defineProperty(String.prototype, ...) instead.

It is hinted, but not explicitely stated, that string[idx] is a parenthesis. In other words, "a".findParenMatch(0) should not happen, because 'a' is not a parenthesis.

In JavaScript this indeed never happens, in Haskell it does happen and Nothing is expected.

This should be clarified; especially because in JavaScript, the function is bound to a prototype, which means it can be called on any string, with any idx; and this is exactly the point of extending the prototype. In such a situation, functions are supposed to double check their arguments, and have a well-defined behavior in every case without relying on preconditions.

The random tests only generate tests up to 2 million. Either the description should be fixed or the tests should be updated (tho some solutions will get invalidated)

• Ruby 3.0 should be enabled (Refer this & this for more detail)

o not use rounding, use testing for approximate equality.