You could do the second part before the loop instead of doing it over and over, I'd say that's better.

My solution the best! =D

Fixed!

This is true! There was indeed still an issue. I wrote some additional tests to prove this case and re-worked the solution to meet these tests:

The previous tests confirmed that the row

4|#|2|2

when shifted right, would combine correctly to

#|#|4|4

But the solution still combined the row

2|2|#|4

incorrectly into

#|#|#|8

This has been fixed. Please re-try your solution to confirm, and thanks for the feedback!

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

Thank you for your report! You were correct, there was an issue with the test case that has now been resolved. Thank you for your example. It was very helpful for debugging purposes.

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.

Nice kata! I like how you test for different ways of getting around the this issue. I'm not sure if the testStats function is working completely correctly. I had 2 using .bind() in an identical way and one using a lambda function with no extra variables declared; it got the lambda and .bind(), but it also seemed to think I had used a variable to capture this when I did not. Either way, the tests still only let me pass when I actually did use 3 different methods, so they seem to be working in that sense.

Also, you might want put the tests in a iife so the cart variable stays hidden.

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.