Ad
  • Custom User Avatar
  • Default User Avatar

    This comment is hidden because it contains spoiler information about the solution

  • Custom User Avatar

    Well, that's effectively a critic point, here. If you carefully look at the sample tests, you'll see ("have seen"?) that you're effectively solving several tests with the same grid instance. So if you mutate the input, that could lead to troubles, yes. Though... Actually... In the present case... If you think hard about it, you'll see that you still can avoid the deepcopy operation.

    (note about deepcopy: generally, this modle is VERY slow, so if you're in critical need of performances, you should implement your own copying. But that's more a general note than a hint for this kata: the structure being quite simple, you won't gain much with that, here.)

  • Default User Avatar

    Hhm, thanks for the advices.
    There is one point in particular that puzzles me: whenever I visit a letter which is not the last, I change that letter to an empty "" so that I'm sure I will not visit that letter again when searching for neighbours in the adjacent letter. However, in Python it seems to me I'm forced to do a deepcopy of the current board, apply my changes in that deepcopy and start the search again, otherwise I would just copy the reference to the board and all changes would apply to the initial board, leading to errors.
    This is presumably very costly, then again I wouldn't know how to efficiently differentiate between visited and not yet visited.

    Also, I don't understand what you mean when you say "verify that you do not explore branches where you actually already know that there won"t be any match". How can know a priori? I can't figure a way to stop the execution beforehand without actually trying all possibilities.

  • Custom User Avatar

    basically, your approach is good. I think you should check that you store the data in an efficient manner, then verify that you do not explore branches where you actually already know that there won"t be any match. Be sure you don't any any useless O(n) check or archiving that should be O(1): that especially would be the "death of your code".

  • Default User Avatar

    This comment is hidden because it contains spoiler information about the solution

  • Default User Avatar

    Thanks! I thought it was my fault

  • Default User Avatar

    Turns out you have to check for non-legal characters when you encrypt AND also when you decrypt

  • Default User Avatar

    I have the very same problem. Did you happen to find out what we are supposed to throw?

  • Default User Avatar

    Very interestingly, I found out for large test with large integers like the ones above, the CW compiler adds a space at the beginning of the string, but the same does not happen on my machine.
    I was able to make it work by searching a space in the first position and eliminating it.

    Could it be there's a space too much in the given string that my code brings at first position?

  • Default User Avatar

    I think there might be some issue with the random test, as I'm able to pass the fixed tests without any problem, but then

    Expected: equal to 104008 106342 210355 44521 7900 93104 162226 319043 32861 332183 13890 266232 229343 8924 490075 187065 445384 489034 64378 381959
    Actual: 104008 106342 210355 44521 7900 93104 162226 319043 32861 332183 13890 266232 229343 8924 490075 187065 445384 489034 64378 381959

    Expected: equal to 203001 71008 231821 445004 174702 146283 314880 175345 464074 146539 448480 497314 209659 415894 457537 137399 384479 369576 118999 399886
    Actual: 203001 71008 231821 445004 174702 146283 314880 175345 464074 146539 448480 497314 209659 415894 457537 137399 384479 369576 118999 399886

    and I don't have any initial or final hidden spaces

  • Default User Avatar

    Looking at the other solutions, I seem to be the only one using the function replace(), so I believe in the end nothing is wrong with the translation.
    If anything, complex ASCII characters seem not to be supported by replace() and this might or might not be a C++ bug.
    All good then.

  • Custom User Avatar

    Thanks for your feedback.
    It seems that finally you solved it.
    C++ version is a translation from @Dentzil, I don't know C++ ;-)
    Please tell me if really something is wrong in C++ version(I copied your code and run, it passed all tests)

  • Default User Avatar

    In the end I was able to solve the problem by writing each line with 'x' and 'o' characters and then changing them one by one with the corresponding square.
    I suspect the whole fuss is caused by the function std::string.replace()

  • Default User Avatar

    OMG, this is ridicolous...

    BasicTest1
    Expected: equal to

    Actual:

    BasicTest2
    Expected: equal to
    □□□
    □■□
    □□□
    Actual:
    □□□
    □■□
    □□□
    BasicTest3
    Expected: equal to
    ■■■■■
    ■□□□■
    ■□■□■
    ■□□□■
    ■■■■■
    Actual:
    ■■■■■
    ■□□□■
    ■□■□■
    ■□□□■
    ■■■■■

  • Loading more items...