The previous bug with shifting up in random tests is fixed, but there's a new one. Here's a random board shifted down. Notice the test solution combined the first and third column twice, rather than once. I've seen the bug in all directions, but only on the random tests (the static tests for combining more than once give the correct answers).

Initial:
2|##| 2|##

##| 2| 2| 4

2| 8|##|16

4| 8| 4|##

User solution:
##|##|##|##

##|##|##|##

4| 2| 4| 4

4|16| 4|16

Test solution:
##|##|##|##

##|##|##|##

##| 2|##| 4

8|16| 8|16

There is something really weird about how you're doing the random tests. Why are you calling the user-provided code in both the "expected" AND the "test" case? Particularly when you're calling it with empty arrays, which was not something in the original design spec. I would expect you would write your own code to calculate the "expected" outcome and only call the user provided function for the "test" outcome.

Here's some sample output. Notice both the return values are prefixed with my initials, which I added to the return values when I was trying to troubleshoot why sometimes I'd get an infinite recursion case.
It should work for random inputs too - Expected: ''PMV: Recursion depth too high'', instead got: ''PMV: nobody won this time''

What appears to be happening is that you have a recursive solution, but rather than recursively call your own implementation after eliminating candidates, in at least one code path you call the user's implementation. It happens when all candidates have been eliminated (you pass in [ [], [], []] etc. )

If you saw the announcement yesterday, they redid how much honor doing katas gives, sometimes by a very large amount in the case of the high ranked katas: https://medium.com/@Codewars/honor-and-leaderboard-updates-a1491f2cb2e2 . The changes are retroactive but the system seems to still be doing those updates as we speak.

That's a very elegant solution - thank you!

Hint: Simplify the equation first, don't try to calculate the two terms separately.

Yes, it is meant to be (7 ^ (6 ^ 21)).

No, because (7 ^ (6 ^ 21)) mod 10 is not equal to (7 ^ ((6 ^ 21) mod 10)) mod 10.

You should definitely add tests for 90.01, 180.5, etc. which a lot of the solutions here would fail on. And then test for 90.00, -180.0, etc. as well.

Same bug. I can validate my solution works as expected with manual verification, and the expected value makes no sense.

It's not a bug per se. It's checking each test twice, to ensure that if you pass the same node in again, you get the same output each time. That's not really an unreasonable test case - one would expect a count to return the same value each time it was called.

Is there a process by which a beta kata that is seemingly abandoned can be updated by a new sensei? https://www.codewars.com/kata/2048/javascript has the potential to be a good kata, but one set of the author's random tests is broken, making the kata effectively insoluble (unless you get really lucky) since the introduction of random tests two months ago. I logged the issue again, as it had been previously reported in comments to a resolved issue, but the author hasn't been around since October so I am not sure it will get fixed.

It is a shame because it's kind of a fun little problem to solve.

The random tests for "up" are broken as mentioned in comments.

As proof, the "expected" arrays often have empty cells above non-empty cells, which should be impossible for any "shift up".

One of the randomly generated problems was a shift up of:

8,16,4,0
2, 0,2,4
2,16,4,0
16,8,4,2

My program's answer, which I have verified by hand, was:

8,32,4,4
4, 8,2,2
16,0,8,0
0, 0,0,0

The answer expected by the random test was:

8,32,4,4
4, 0,2,2
0, 0,8,0
16,8,0,0

Note that 16 and 8 in the bottom row have blanks above them - which is not possible after a shift up operation.