I raised an issue for such cases, referee solution is indeed falsy.

Thanks for pointing it out! Yep, the cap was faulty. Applied some fixes, and now it looks like it computes this list properly. I hope the issue is settled.

🖖

JavaScript translation awaiting approval.

Marking question resolved.

Done, I think. I also tried to make it look a bit better.

you should add to the description the equivalent linear string, used as input (below the second grid)

I'm pretty sure I've swapped them around now.

I've changed it so that for the random cases, it randomly decides to either do no errors (20%), a message error (40%), or a parity error (40%), and have combined the larger and smaller tests into one batch.

I mostly am doing many tests because an answer which is almost correct might only fail in a small number of cases, and I wouldn't want slightly wrong answers to pass just because the case where they fail didn't come up in the testing.

almost: the problem is that you announce to the user where the error will be ;)

=> you need to merge the 3 batches and pick randomly a strategy when you do one test. (note: is that necessary to do that many tests?)

I recently had to change how I did it to resolve one of the issues raised, so the examples now look like:
Test.assert_equals(correct(2,3,'11111010001'), '11111010001')
Test.assert_equals(correct(2,3,'11011010001'), '11111010001')
Test.assert_equals(correct(2,3,'11111011001'), '11111010001')
Test.assert_equals(correct(2,3,'11111010011'), '11111010001')
So it is '111110' + '10'(rows) + '001'(cols). laid out it looks like:
111 1
110 0
00 1
I think your looking at the previous versions of the examples, which made sense then because I was doing columns and rows the wrong way around.

You're right. I believe I've now swapped the M and N to be correct, but it required many changes so I may have done it wrong :/