-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
legal-moves in play.py might be better if sucide check added #12
Comments
It would definitely help for sgf inspection, as most sgf readers I checked pop warning for sucides. However, checking for sucide placement seems a bit expensive (I probably need to copy the board, add the stone, and check for self-capture, for every otherwise allowable move.) I would also like to check that the algorithm can learn on its own to avoid these bad moves. |
if add self fill eyes check to mask in play.py(line:12) it might be much better |
Yes, you can add it after the KO situation. TBH, I think a simple west, north, east, south check might be enough (and not do the the more general add stone, check capture). In any case, we need to check was it the performance impact before adding it into master. |
I noticed that if no self eyes check, it takes more than 700 moves to finish a game and even 722 moves, especially, the win/lose judgement is incorrect and it will affect the learn process. |
Playing into self eyes is a legal move so I won't add it into the legal_moves as the paper mentions it simply implemented the Tromp-Taylor rules (which do allow sucides as well). But feel free to do it if you want. You simply need a simple check North, west, east and south. I can check your code if you want. |
I have tried the following, but I am not sure if it is right. need your help , thank you!
|
Ok. It has a few bugs, but it is the general idea. You need only to check 4 places, not 8. Advices:
|
Many thanks! I'll try. |
another change, and it seems working fine for now:
def legal_moves(board):
|
I gave a little more thought about this code. It seems it would work for self fill. Although a few tests would'nt hurt to make sure. Your implementation works for self fill, but it won't work for sucide, because in order to assess if a sucide is playable or not, you NEED to check if the sucide does not capture first. For instance, consider: . X O O O X . . Then position P is allowed even though your code forbids it. I would have been happy to add self sucide flag. For self fill, I'll start an experiment to see how fast it improves learning, and I'll get back to you, it really feels a little cheat (the algorithm should somehow learn that on its own). By the way, what settings are you using and on what kind of hardware ? |
For efficiency consideration, the suicide check might not be added to mask. It will take much more time than the simple mask check because it must be assessed if a sucide is a playable move, while, it might improve the performance in general. We can put a "IF ..." before the Self Fill check section to improve check speed, for example, "IF moves>100", when total moves more than 100 or 200,etc, but we need a parameter "moves" added to legal_moves. Also, I met a running time problem: My setting: GTX1080, 19*19 100 epochs, 5 games of self_play, 64 mcts simulations, just for testing! |
1/ If you see a bug, can you provide a test for it? 2/ You can add the assignment into the color_board function but it does not change anything as the board is mutable, and _color_adjoint already modifies the board. 3/ This means you don't have any actions available while simulating. This is rather odd, because passing should always be an action at the very least. Did you change the MCTS_BATCH_SIZE ? MCTS_SIMULATIONS should be at least larger than the batch SIZE (so it can do at least one batch). Can you open new separate issues for these ? |
I have made a few "fixes" as following, and the result seems more reasonable! and get_winner function works fine, though we may not need it anymore! ^=^ (still working on it, but takes time ^=^).
|
No description provided.
The text was updated successfully, but these errors were encountered: