Thanks natan, I will give that a try.

That's an interesting situation you found. It's a strange thing to be testing without any corresponding specification - it has purpose but I think the test output should be phrased differently because that's bit of a red herring. If you print out your parameters a b c that should tell you enough to continue.

Enabled in this fork

The input range should be specified. Without it it's unclear what performance requirements are or what type should be used for intermediate values in C.

Approved by someone

Nice job on your first kata, Alex!

When I was 27, I thought I had invented run-length encoding. Then I found out it had been used 20 years earlier in the transmission of analog television signals. Oh well.

Here's a case where a Sieve of Eratosthenes worked better for me than a primality test.

Tried my hand at a little memoization here. I'm not sure it made much difference in execution speed on this kata, but it was good practice, anyway.

Sometimes it really pays to come back to a kata that you gave up on earlier. Somehow the first time I looked at this, I didn't recognize that a relatively simple "binary search" approach would work.

Funny how I used to think it was always faster to generate all the primes that you might possibly need, using something like the Sieve of Eratosthenes, but in the meantime I've learned that sometimes a primality test is actually faster. It depends on the task.

Interesting that some other solvers also hard-coded that one case. It seems that some approaches (like mine) work for all tests except that single case.

This is the second game-related, object-oriented kata I've done recently in which I had to set the current player (in the constructor) to the opposite of the player who's supposed to start the game -- because the current player is reset near the beginning of each round of play.

But it is.