2 kyu
Chess - checkmate with rook in 16 moves
15 of 41user6793616
Loading description...
Games
Performance
Algorithms
View
This comment has been reported as {{ abuseKindText }}.
Show
This comment has been hidden. You can view it now .
This comment can not be viewed.
- |
- Reply
- Edit
- View Solution
- Expand 1 Reply Expand {{ comments?.length }} replies
- Collapse
- Spoiler
- Remove
- Remove comment & replies
- Report
{{ fetchSolutionsError }}
-
-
Your rendered github-flavored markdown will appear here.
-
Label this discussion...
-
No Label
Keep the comment unlabeled if none of the below applies.
-
Issue
Use the issue label when reporting problems with the kata.
Be sure to explain the problem clearly and include the steps to reproduce. -
Suggestion
Use the suggestion label if you have feedback on how this kata can be improved.
-
Question
Use the question label if you have questions and/or need help solving the kata.
Don't forget to mention the language you're using, and mark as having spoiler if you include your solution.
-
No Label
- Cancel
Commenting is not allowed on this discussion
You cannot view this solution
There is no solution to show
Please sign in or sign up to leave a comment.
I have created a rust translation, please review and approve!
I think the random tests are somewhat limited. The 500 tests pick from 916 unique boards (generated from 121 base triples, then rotated or mirrored, with a bit of overlap between rotations for 52 of those).
I know one of my solutions had a bug in how states were generated where it missed some options, and I was wondering why the random tests never touched on those positions. Now I know why!
There are nearly 10k possible chess board arrangements that would make a valid test:
Is there any reason why these are not simply properly randomly generated?
It depends what you mean by "properly randomly generated", but if you mean 100 or 1_000 or 10_000 tests generated with random spray, then this would not help much either? You will always have some potentially interesting positions which will not make into the tested pool. The best way would be to generate and test all possible board setups (modulo transformations), which would boil down to a couple of thousands of tests cases I believe? Is it possibl to test this task by running the solution on all "uniquely relevant" boards?
Why not a mix then? The 918 boards are, I think, too small a pool.
At any rate, here's my tester script, which relies on
python-chess
to do the heavy work.The number of boards can be revised downwards a little, to 88060.
Dang I'd have to do some math but 88k is WAY more than I expected it to be. I am also not sure how your scipt handles discarding of equivalent, rotated/flipped boards, but I can't test it today, I will try tomorrow.
It doesn't discard rotation and mirror variants, no, but that's because I wanted to be able to compare the number to the expanded number of unique boards used in the random tests. There are 121 test positions, but when you rotate and mirror those, there are 13 boards where both kings are on the same diagonal. These boards produce 52 expanded boards instead of 104, so you get a total of 121 * 8 - (4 * 13) = 916 expanded boards.
When you just randomise the positions based on bitboard masks like above you don't need to expand afterwards anyway.
The following variant of the script does limit itself to just the 1/8th B2D2D4 wedge of the centre for the black king positions and limits the white king to the larger A1H1H8 triangle when the black king is located on the B2D4 diagonal:
There are 11340 such boards, with 665 positions where both the kings lie on the A1H8 diagonal, so these expand to 88060 unique chess boards:
Here is a version that doesn't use the
chess
module and yields just the square names:or, alternatively, a version that picks a random position out of the 11340:
or a version that doesn't need subsequent rotations, so picking from the 88060 unique boards:
Right, I finally figured out what I was missing: The random board states are those positions where black will lose in 16 moves. All the other states my random generator produces are states where black loses in fewer states. 🤦
I get there in the end..
This comment has been hidden.
This comment has been hidden.
It's incredibly satisfying to finally be finished. It wasn't easy, thanks for a great and challenging kata. IMHO, it was closer to
1kuy
than to2kuy
. And I agree with comment @Voile, I think this is indeed a problem and should be taken into consideration.This comment has been hidden.
This comment has been hidden.
Then it's definitely not a 2kyu kata, maybe 5kyu at best. Whether you had fun solving the kata or not is an entirely different matter (that has nothing to do with the difficulty assessment).
This comment has been hidden.
This comment has been hidden.
Node version needs to be upgraded from v8.
This comment has been hidden.
OK, I have reduced the number of tests by a factor of 10.
I am not sure I agree with this... My solution is an example of one which has largely correct logic, but with many specific cases that it handles wrong. Yesterday when there were 500 I was passing anywhere between 1-150 of the random tests, but usually about 20-30 before finding a case which I handle wrong. (You can fork the solution to test it out yourself and see how often it fails)
I think for a purple kata its fair enough to require high performance, but thats just my opinion. If the new low amount now allows for 'basic' search algorithms, etc. then this might even be blue.
This comment has been hidden.
Yes you need a lot of tests to get enough variety.. forgot about that. 50 probably isnt enough. About performance, I dont know if you could do a basic search algorithm that consistently needs 16 moves without implementing a lot of logic (and being somewhat fast). But maybe thats wrong
I reverted the change on the number of random tests, and added a paragraph in the description that references the Chess Endgame Database you referenced, Kacarott.
Thank you for the suggestion!
Working through the kata, a really nice bonus feature would be a visualisation of the board on failure, similiar to some of the "Play Game" series katas. Here you could directly just use ASCII as there are unicode symbols for the pieces I believe.
Just an idea :)
Glad you took the time to work on this kata, and thank you for the suggestion! What state of the game would you suggest to include in the output? The starting position, the position before the last one or two moves, or all states of the sequence from start to end? The latter might produce long output (a sequence could have up to 50 moves)? What did you have in mind?
What I used for testing, was every position when it was white's turn, so comparing two boards I could see where I moved, and then how black reacted. And I think somewhat long output is quite ok, as long as it is only produced when the user fails a test (and perhaps it could be an optional thing, that the user has to set
DISPLAY = True
or something)Why is this kata listed in the 8kyu section?
No idea. It doesn't make sense. I estimated its difficulty to 2 kyu when I created it over a year ago. But I guess no-one has ever since given an estimation for it, so I don't have any hope anymore something will happen with it.
This kata is feeling so lonesome...
There is a magical function that prevents user code from tampering your objects, and that is
Object.freeze
;-)Thanks for the suggestion for JS. Implemented. For Python I have kept the code as-is.
The sample tests do not respect the contract: with them, you are asking for some "somewhat specific implementations" that will identify the perfect move to make mate in one move, but maybe the user could still make the checkmate in less than 16 moves, doing something else. I still didn't press attempt, so I don't know if that's the same for the full test suite, but if so, you have to change the way you test the solution of the user (or to change the contract/description)
This "exception" was intended and mentioned in the description, as well as whether this would be applicable to the full test suite. Maybe you missed that part?
True, such example tests assume that a solution would always find a mate in one, but I have trouble imagining a solution that would somehow not go for the direct win, so I consider such example tests to actually help with what one would want to achieve first in doing this kata. Maybe my imagination for alternative solutions falls short... On the other hand, if the example tests would have to play a game for potentially 16 moves, they would become unpredictable and thus need much more logic, which would maybe give too much code that could be reused for solving the kata itself.
Seems so.... x)
about the tests, what you can do is put the "tester" in the preloaded part (being sure it cannot solve the task in place of the user), then, you put a copy of it in the test cases, so that the user cannot abuse of that preloaded part (you can even delete the function at the beginning of the test cases, to be sure). This way, you could have sample tests following the contract (take a look at doc's hard kata, this is the wy he implements them, generally).
About the logic/imagination and all, I honestly don't know. I honestly think I won't solve this one (the only way I could think of for now is to build sort of a FSM. I can picture the general thing by playing the game myself but cannot see how to actually implement it...), unless spending A LOT of time on it.
OK, you convinced me ;-)
I put the black player's logic in the preloaded section, and now the example test cases use the 16 move limit.
I hope you will not give up on this too soon.
EDIT:
You're right, that solution setup could have given the impression that some properties are required to be present. This is not true, so I have removed that code and instead added the suggested parsing in comments, as I don't consider that parsing to be relevant to this kata's objective. I could of course have given the positions as individual arguments, but I prefer the human readable (and common) position format.
It is true that the initial position of the black king is not adding anything, but I prefer to stick with a complete initial position. Leaving out the black king could come across as strange to some. Anyway, you are free to ignore it. ;-)
I had taken the default choice of the Python version :/ So now it's updated to 2.7 which indeed is a tad faster.
There are currently 500 random tests in the Python version, and 10 000 in the JavaScript version.
ah no, don't default it to 2.7, please. rather, put that in the preloaded part:
so that there is not "perf cheat", but enforcing 2.7 seems just very wrong to me... ;)
About the input, the string format is perfect, and I wouldn't even provide the parser. Considering the task, it's absolutely trivial ofr any user who will attempt the kata. ;)
OK, version is now 3.6, and I added the preloaded code you suggested. Thanks!
I removed the parser from the initial code. You're right, it should be trivial.
ok!