Loading collection data...
Collections are a way for you to organize kata so that you can create your own training routines. Every collection you create is public and automatically sharable with other warriors. After you have added a few kata to a collection you and others can train on the kata contained within the collection.
Get started now by creating a new collection.
.
This comment is hidden because it contains spoiler information about the solution
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.)
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.
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".
This comment is hidden because it contains spoiler information about the solution
Thanks! I thought it was my fault
Turns out you have to check for non-legal characters when you encrypt AND also when you decrypt
I have the very same problem. Did you happen to find out what we are supposed to throw?
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?
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
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.
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)
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()
OMG, this is ridicolous...
BasicTest1
Expected: equal to
■
Actual:
■
BasicTest2
Expected: equal to
□□□
□■□
□□□
Actual:
□□□
□■□
□□□
BasicTest3
Expected: equal to
■■■■■
■□□□■
■□■□■
■□□□■
■■■■■
Actual:
■■■■■
■□□□■
■□■□■
■□□□■
■■■■■
Loading more items...