While this works with all of the test cases, it limits the tape to 30,000 whereas the requirement was that the tape be infinitely long (though obviously it'll be limited in practice by memory). To be correct, the tape should be extended dynamically in either direction as required.

If arr has an odd number of elements then this code invokes undefined behaviour by accessing past the end.

This incorrectly returns true for cases where the substrings exist but in the wrong order (though there doesn't seem to be a test case for this). For example:

solve("wars*code", "codewars") // true

This incorrectly returns true for cases where the substrings exist but in the wrong order (though there doesn't seem to be a test case for this). For example:

solve("wars*code", "codewars") // true

This seems to occur if there is too much output written to standard-out. Since some of the test cases can be very large, it's easy to end up writing too much output for this test. Try removing any debugging output.

Based on some of the older comments, it appears that people used to receive this error instead:

Failed to process output. It is possible that too much data was written to STDOUT.

Perhaps that functionality has changed or is broken.

Thanks, marked as resolved.

That's part of the definition of what the median is: it's the middle value of a sorted data set.

mean = (-10 + 20 + 5) / 3 = 5

median = {-10, 5, 20}[1] = 5

result = same

I can't get one of the random test cases in the C version. The data set is:

31,83,78,68,-121,21,28,65,68,-56,-109,95,-85,-83,-37,-16,-32,36,-103,-46,92,26,-102,76,62,-27,-35,-28,-59,24,-111,100,-19,95,43,-11,-9,-54,-71,-66,18,-52,-96,62,-7,-5,-80,90,-95,-54,-82,-128,100,-55,77,37,46,-84,-117,115,68,-100,90,-76,124,8,41,-10,82,98,52,-26,-79,84,-89,43,-46,-40,7,-12,34,54,-12,9,-127,-60,-80,48,-16,-68,37,-73,-40,2,-20,-41,-116,-105,77,95,122,4,-56,-83,-37,-17,88,45,71,-30,-93,-20,-102,24,117,-101,92,-88,75,-49,-28,-13,7,61,118,115,-106,-123,-115,100,100,-118,-22,-82,-73,69,30,-110,-11,-25,-12,24,84,15,-77,76,42,-110,116,-8,-31,-38,108,104,-102,100,94,-80,106,107,-106,80,117,1,-127,-81,-56,31,-62,62,-119,55,-39,93,-56,12,43,115,30,34,-19,-126,124,-36,107,-103,-61,75,-55,-81,57,-32,-127,49,97,-126,97,-84,34,-91,107,43,92,-58,11,-89,82,-72,-100,-14,90,10,-11,89,103,-30,114,-84,-81,-66,-37,105,31,-35,28,3,-32,-1,48,-124,37,29,48,4,99,-67,43,55,-11,72,-84,-46,-44,34,-82,-67,-122,-93,-22,-75,-31,69,-96,-125,-92,61,6,5,-66,-71,9,99,86,-69,-23,59,-7,-105,-11,111,95,34,-61,-74,-58,-15,-12,-52,20,94,2,118,38,35,122,74,-30,2,-47,33,60,91,7,20,-103,113,-46,18,-117,71,3,106,-20,71,-93,51,-69,23,-126,80,-8,4,72,-96,-86,69,107,13,-54,-66,-79,-120,-100,56,28,-75,44,110,72,55,56,-51,35,-89,-106,71,90,-47,-32,92,-92,89,-29,108,121,13

The output of my solution is mean: -1.242775, median: -3.000000, largest = mean

I've even tried plugging the values into online mean/median calculators, which give me exactly the same results. As far as I can tell, this answer is correct, yet the test case fails.

The same solution ported to C++ passes all test cases, so I can only conclude that either I'm doing something stupid, or the C tests aren't quite correct.

The C# example test cases seem to be broken. They're referring to static TreeNode.MaxSum method but the MaxSum method actually belongs to a class called Solution. The real test cases run fine.

This will cause a new allocation and string copy for every character, which is quite inefficient. You know how big the resulting string will be at the start, so you should just allocate one buffer for it and copy the input string into it once with the desired replacements.

It will also leak every buffer that's allocated except the last, which is returned to the caller. If you want to resize a buffer, you need to malloc a new one of the desired size, copy the contents from the old one and then free the old one. Or just use realloc.

The Kata description seems to hint that there is a requirement to validate that the length of the input is a perfect square (nxn), but this isn't clear and there appear to be no test cases for this.

Should be done now.

The point of the Kata was to use the Null-Conditional operator.

No; it's easy to make that mistake on first glance, but a closer look reveals that the dictionary contains a series of lambda functions. Only the one selected by the key (day) is actually then executed.