bad testcases: 6 appears three times - Expected: [[6, 1], [4, 2], [6, 5]], instead got: [[4, 2], [6, 1], [6, 5]]
many other numbers appear four times - Expected: [[10, 1], [5, 2], [5, 3], [10, 9]], instead got: [[5, 2], [5, 3], [10, 1], [10, 9]]

I similarly was annoyed that we had to round the distance. I ran into a weird problem using int() vs round().

from math import sqrt
r2 = 5
rA = int( sqrt(r2)*10000 )/10000 # 2.236
rB = round( r2**0.5, 4 ) # 2.236

This happened ONLY when r-squared equalled 5.

Even although the first sentence calls for an accurate solution, many current solutions, including the one with most "best practices" upvotes (4), will fail the following test case, which I think should be added to rule out the not-quite-right solutions:

test.it("is accurate ;-)")
listPointsA = [(0,0),(2665,4242),(6397, 7584)]
resultsA = [3, [[(2665, 4242),(6397, 7584)]], 5009.6695] # note that 5009.6695 is also the rounded distance of (0,0),(2665,4242)
test.assert_equals(closest_points(listPointsA), resultsA)

I am not aware of a general solution, and if one were known, I suspect Singmaster's conjecture would rather be known as Someone's theorem.

Anyway since n-choose-k >= n for all 0<k<n, you only need to sample finitely many canidate solutions for any given finite a, so a provably correct overall solution must exist. (I am not sure how to prevent that kind of brute force, but for large a it will probably time out already.)

One should be able to pass all tests with this approach, i.e. find (n,k) candidate pairs and check whether n-choose-k == a, if the candidate pairs are picked more reasonably.

I haven't yet given up on this kata, but I would like to know:

Is there an actual, general solution for this problem, or should I cobble together something from OEIS series, rules about primes and powers of them, and educated guesses that are not provably correct?

Well, the random test does not check your solution against mine, it only did a rather rudimentary plausibility check. I expanded it to do more plausibility checks. :-)

Oops...Fixed. (I had just copied the a section of the full test cases there. Seems I cannot run the example tests only from the author interface.) Sorry for the inconvenience.

Thanks for the hint ;-)

Example test is using it when it should be using describe, which makes them not working:

"it" calls must be invoked within a parent "describe" context

To see the tests, I submitted with return [].

All the random tests passed. Is that supposed to happen?

When I did the translation, I didn't put anything special in the way the tests are done. So I think this is due to cw's way to handle Junit tests. I cannot do anything about that.

Debugging with Java on cw may often be a pin in the ass... ;-/

No need to investigate, after I fixed the off-by-1-error my solution was fine. :-)

However, if I run class Main {public static void main(String[] args) { Integer.parseInt("X"); }} at repl.it, I get Exception in thread "main" java.lang.NumberFormatException: For input string: "X" (and even more detail), so I blame the test setup here at least partially for not letting me know that there was a NumberFormatException involved, which would have been enough information to find the problem.

Is the disappearance of the Exception name (or the fact that there was an exception at all) due to the way codewars runs the test or specific to the test setup of this Kata?

Well, it seems that the trouble lays on your side. ;)

Not knowing your code, I cannot help you further so I'll let you investigate a bit your code (with the console! ;p ). Let me know if you encounter troubles.

Thanks for the reply. Re: input in the console: Nope, must have been too tired to think of that. :-)

The problem was (I hope that is not spoiler-worthy...) Integer.parseInt(...) throwing (and only a little bit of the exception message reaching me): I thought I checked whether the parseInts input was Integer-parseable in the first place, but actually checked the wrong thing (index off-by-1).