The issue marker is for when there's an issue with the Kata itself. Not when you have an issue with figuring out a solution. And certainly not when you have trouble understanding some code you found on the net.

I would suggest that you try to write a solution yourself.

Also, this is not an issue with the Kata itself, so it shouldn't be marked as an issue.

Hint: does the string variable that you check in the loop contain only lowercase letters? (Answer is "No")

I see the number 4 and there are 3 solutions listed.

I also see that you ran into a testcase that would overflow. Apparently my (admittedly somewhat excessive) use of reducing all fractions - both inputs and any intermediates - gets around that issue without needing special code.

Aren't is not the same as Aren'T

I just finished solving this in C# and I had no troubles with the existing test cases. But I think it is missing at least one test that should have been there.

[25, 25, 25, 100] should return "Yes" - My currently passing solution would not pass this case, but because such a test isn't in there, my code passes.

I just completed this Kata for Pascal. Before this it showed as having been completed for Pascal 2 times, and now (including mine) it says 3.

However, I can only see one other solution (by g964). Is this a bug just for this Kata or a general bug? Or maybe a solution is hidden somehow?

Oh, and the issue-marker is only supposed to be used, when there is something wrong with the kata.

The kata works fine for JavaScript - there's almost 300 people who managed to solve it, so the issue is with your solution, not the kata.

Factorials grow absurdly quickly. So much that normal integer variables can't contain them.

Luckily, in this case you don't actually need to calculate the factorial of any number. Try shuffling around the terms in the choose function.

Hey, could you make me a poster with these seven colours?
Sure, here you go. (Hands back a blank sheet of paper.)

I know that it's mathematically correct to expect x=0 for any m=1, and that it's probably way too late to change the kata, but I think the expected result should have been x=n, which would have been a nice little special case that needed to be handled for some implementations.

A float probably isn't the best choice of variable type. And if you actually calculate factorial(n), you are likely to overflow a small-sized integer.

Hint: You don't have to actually calculate factorial(n). Try shuffling the formula around.

Hint 48 choose 11 = 22595200368 which is not equal to 6540715897

1. 22595200368 != 6540715897. The kata asks for strict equality, not merely enough possible combinatons.
2. Yes, I agree that x=0 for any m=1 doesn't make much sense for the real-world scenario described. However, if there should be another answer, 1 is clearly wrong (once again, it asks for equality), so then the correct value of x would be x=n

Sorry, I just couldn't keep myself from responding to the combination af that comment in the code along with that indentation. (And I don't think there's any way for me to see how old that solution is.)

On the plus side, you can see this as a reminder of how you have improved since then.

It doesn't say that you must ensure that the number doesn't go below 0. It is a promise that no test case will result in negative numbers.

But this raises another issue: I'm pretty sure that the random tests (in C# at least) are not constructed in such a way that no negative numbers can occur along the way.