omg xDDD, but i guess if this is the case, then it should be something like 8 kyu?

I wasted my time because of the gaps. It was a useless endeavor.

approved

Enabled in this fork

lol

Most intelligent LLM user

No information is given about the order of checking the pixels. Each person can assume a completely different search order and arrive and completely different answers because of this line: "summing the differences between... the pixel that was matched last with the new candidate pixel."

The order matters.

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.

Don't confuse so easily. Closing.

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.

If you can provide some descriptions of cases you would like tested then I can add them.

JS fork

• Markdown description
• Updates to Chai + assert
• Improves test runtime
• Removes weird nonsense from solution setup
• Removes console.log spam in the tests

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.