I would add further that if you'll look for a pattern in the comments, it seems that a higher proportion of higher ranked users made comments than what might be typical of a 5 kyu problem. I think that might be corroborating support for my previous reply.

The basic tests all pass. Sometimes the random test are off significantly, sometimes they're off marginally, and occasionally it passes. A little greater clarity in the description and/or adding tests that are more reflective of a possible random scenario would be helpful. Normally, if I have random tests failing, I simply log the input to refactor my code against. It's much more difficult to take that approach in this case. Again, it's just my opinion.

What pattern would be different in the random tests?

The instructions could be more explicit. Also, if the random tests are going to break pattern with the visible tests, it might be fair to include an example of that function call signature. I prefer a challenging concept over a challenge to gather the author's intent. Just my 2 cents.

I solved it in a similar way without opening google.

This was a straighforward kata, AFTER deciphering the expectations. The description could be written a bit more clearly. Some users are not working from a freshly studied CS algorithm textbook, and thus are actually drawing upon purely reason, logic, and programming utility, and may not associate this with the better known 'connect the ropes' to provide valuable context in the acceptance criteria. Examples showcasing the malleabillity of subsequent ordering, e.g. the cost need not necessarily be added immediately in the operation immediately following the addition of two elements.

Whereas the mathematical solution to this is impressive, this one is more easily found under a simple Google search, and thus gives up something in the way of originality. To those who solved it without opening any tabs, kudos!

To be honest, the actual solution set isn't near the extreme of challenge, but the expectations are somewhat ambiguous. Perhaps more/better examples of expected inputs could be provided.

I actually have a live version of this game, and a couple of others in javascript and jQuery, at www.cj-innovations.com . Personally, I wouldn't have used the prototype chain and newing up instances for the problem. I would have used a simple function called "compareHands" that would take 2 arguments. That's just my personal opinion. It makes it easier to jump between text editor and test environment, and allows greater focus on the algorithm itself. Take it with a grain of salt.

Damn, i had the same issue. thanls for clarifying

I just passed 51 tests, and I'm still getting a timeout failure. A previous comment suggested that the number of tests is lower than this number. Have the tests been changed?

Thanks, I really appreciate it. I was thinking the given constraints only applied to the first summation. Since the second summation can exceed the limit, I assumed it could go below the start also.

2024 is smaller than 2177.

I'm having an issue that isn't making sense. I'm passing 47 of the tests, but I critiqued the first point of failure by grabbing the input with 'console.log' and I double checked the math by hand, and a solution exists, but the test case expects 'Nothing'. The first case occurs when the inputs are 2177, 4357. The solution my code returns is [2295, 2024], which meets the s(n) + 1 = s(m) + 1 standard. I appreciate any insight into this anyone can offer.

Actual and expected were flipped in PHP.