This function is not an error handler nor is it designed to scale.

I am noticing this same problem with python kata. I am passing the 4 examples and all basic tests:

Test.assert_equals(solve(0,20),14)
Test.assert_equals(solve(2,200),457)
Test.assert_equals(solve(2,2000),17705)
Test.assert_equals(solve(2000,5000),25005)

And, passing about 4 - 8 random tests. However other random tests between ranges of about 500 - 1000, I am failing. There are no timeout issues, my algorithm simply returns the wrong number of primes. Strange how I'm passing some tests yet failing others despite their ranges being within the same numbers?

UPDATE: I ended up passing this one, without changing my code, similar to the above user, Cptnprice.

I suggest adding a test that has different repeated numbers for both input cases.

For example:

num1 = 9875222143465
num2 = 24236884

• the repeats are 222 and 88
• Should return 0.
• My code would have returned 1 had such a case existed.

I don't believe these cases exists because I built code to return True (i.e. 1) for these cases, and didn't realize it was wrong until my code passed all tests, I submitted it, and saw the other solutions didn't account for such cases.

Inspiration for this kata: https://twitter.com/officialjaden/status/329768040235413504

I added a more clear description and 1 example test... Also added go translation. Can you approve the updates?

I updated description to be more clear on what exactly the return type and string should be since many people have noticed the description with "hello world!" to be confusing. I also added a go lang translation. (Suggestion tag means suggested edits)

I wasn't sure why index.html was chopped out from the breadcrumb, yet holidays.html included until I read the instructions more carefully ->

"if the name of the last element is index.something, you treat it as if it wasn't there, sending users automatically to the upper level folder."

The function is not designed to handle errors or scale. These things can be handled in separate function calls...

To handle the errors you suggest the original template function would have to be modified to have return type pointer (double *) or the errors would be handled before the function call.

Awesome solution, I feel like I just took CS 300 Python course trying to learn this code. Incredibly fast runtime too!

I think the author prefers people to find out how to handle duplicates by reading the discourse section, since the vague note in the instructions, "(with <)" has been unchanged despite all the suggestions to clarify it.

Hi Thanks for the tips! I did notice that the output for the test case in which my algo had the too slow runtime was printed in the error message, so I did use that test case to modify my algo. In case anyone else has my same error, I had to notice the # of unknown squares, '?', surrounded by only unknown squares, '?'.

The testing suite was great and very helpful, great kata, I finally solved it!

Hi I've just completed 24 tests and the speed check ran at 1.00 second flat (needs to be about .02 for python), receiving the "DAMN!" too slow response (I've already improved my algo by about 5x, before it was ridiculously slow :( ). I've been using the trial and error (brute force) approach of guessing for '?' spaces that do not fit the standard logic of perimeter #bombs = center space #, but now I see that I need to improve my algo for even these cases. From wiki (http://www.minesweeper.info/wiki/Strategy), I see that the 1, 2 and 1, 1 patterns are helpful. I'm working on incorporating these. Any other tips on Mine Sweeper Logic would be very helpful, please before I spend another day or 2 slowly dying by this problem.

Good show, finally solved this. Great testing suite. Props to the authors!

Thanks I just noticed the Alphas skip.

I believe there is an issue with Python tests for handicap coordinates of 13x13 and 19x19. The tests for 13x13 expect that all the right most handicap coordinates to be located in Column "K". However the instructions show that 13 by 13 right most handicap coordinates should all be located in column "J".

I believe this because I am printing the input from .get_position(). If I am wrong, sorry about this, and I'd appreciate some help if there is any. I have not yet debugged the 19x19, but I believe it is the same error of expecting coordinates too far to the right.

From the instructions:
9x9                13x13
                   A B C D E F G H I J K L M
. . . . . . . . .  . . . . . . . . . . . . .
. . . . . . . . .  . . . . . . . . . . . . .
. . 4 . . . 1 . .  . . . . . . . . . . . . .
. . . . . . . . .  . . . 4 . . 8 . . 1 . . .
. . . . 5 . . . .  . . . . . . . . . . . . . 
. . . . . . . . .  . . . . . . . . . . . . .
. . 2 . . . 3 . .  . . . 6 . . 5 . . 7 . . .
. . . . . . . . .  . . . . . . . . . . . . .
. . . . . . . . .  . . . . . . . . . . . . .
                   . . . 2 . . 9 . . 3 . . .
                   . . . . . . . . . . . . .
                   . . . . . . . . . . . . . 
                   . . . . . . . . . . . . .