Because the combination x!(n-x)! is symmetric with respect to n/2. Ever x>n/2 amounts to a term that was already looped over.

Could you explain why you you put while x <= n/2. I am not understanding why people put n/2 or n//2.

Not anymore.

The idea sounds tempting, unfortunately you would not only need to be a reasonable coder, but a rather brilliant mathematician.

Numbers that do not end in palindromes after any number of iterations are called Lychrel numbers.
There are no such verified numbers in base 10. The smallest candidate is 196, which has apparently been iterated around six billion times or so and has not failed yet. Of course a computer can never provide a proof in any finite time by simply iterating the algorithm.

Even shorter:

solve equation n choose x = m

You are right, what's obvious is usually far from it. Incidentally I had to modify my orginal code, because it began iterating with x=1. When I saw the error, I knew immediately what went wrong. All in all not really an issue.

The problem still persists. If one raises an exception, the tests will apparently not catch it. In result the test framework stops with an unhandled excpetion and fails, although raising an exception is the thing to do, according to the description.

The discussion with @sayfidz is not hidden so you should be able to see it. @sayfidz put a post asking kind of the same question as you.
I reproduce my answer and below his answer.

It's always difficult to transpose a mathematical problem into a day life one.
The solution of n choose x = 1 is "zero". From an artistic point of view it means, for me,
that there will only be a drawing in black and white with no colored paint in the same way
that you say a "black and white movie" opposed to a "color movie" (though black and white are colors too...).

Yeah, you're right; I was overthinking it. I went into it thinking of "color" as RGB = (x, y, z) or something,
so I wasn't expecting 0 to be a valid response. As you described, it's more important to make the
concept accessible, which your analogy does. I also did a small bit of searching and found that
whether or not black and white are colors is a "grey" (ha) area. So I agree, no change is needed.

Did you have to modify your solution to pass the tests? If you follow the equation given in the description you "fall" without problem on the good answer:-)
Thanks for your feedback but be aware that "obviously" is not always "obvious":-)

I didn't see the discussion you had on the topic already. I'm perfectly aware of the math, but since you made such an effort to wrap a maths problem into a real life example, I would expect the solution to behave realistically as well. For me this implies checkchoose(1,n) = n, because otherwise there is need to come up with "an artistic explaination" of why it's zero.

But since the problem and solution are mathematically perfectly valid, I will mark the issue as solved and turn it into a suggestion to alter the description to mention this fringe case.

Maybe you read the description a bit too quickly. checkchoose(m, n) is x such as n choose x = m (See equation (1) in the description). Here checkchoose(1, 5) is x such as 5 choose x = 1. The only "obvious" x is then mathematically 0. Don't you agree? See the discussion below with @sayfidz 3 weeks ago for an "artistic" interpretation of this mathematical result.
If you consider my answer as acceptable, please mark the issue as resolved.

A random test in Python: checkchoose(1,5) should obviously return 5, but the test demands it to be 0.

The typo is still present in the Python version.

Ah, thank you very much! Makes sense. The documentation would be a good place to mention this -- or maybe I just didn't see it.

The test cases in the Python version are broken. They read like:

cc = ''
r = maskify(cc)
test.assert_equals(cc, r)

Output is directly checked against input...