Re: [computer-go] solving the nakade problem
Quoting Ivan Dubois [EMAIL PROTECTED]: Hello, I think there is a very easy and straigthforward solution to the nakade/seki problem, here it is : For moves that are self-atari on a group that contains MORE than 5 stones : Both in the tree and the playouts, strictly forbid them (exactly like you forbid filling an eye). (This is to handle seki and have efficient playouts). For moves that are self-atari on a group that contains LESS than 5 stones : Allow them both in the tree and the playouts. In the playouts, they should be played with a low probability. But they should be played when there is no other move left. (This is to ensure groups with are dead with nakade are eventualy captured in some playouts). What do you think about this solution ? I will probably implement it in Zoe to see if it efficient, unless someone finds a flaw in the logic. Valkyria has a lot of logic about what self-ataris should be allowed or not, and the size of group is part of that. I see two possible flaws in playing the remaining moves self ataris with low probability. a) In some cases the group under attack will appear as alive because the nakade is always always captured in a way that creates a second eye. Just playing all moves with low probability does not mean that the right move is played. Also correct nakade handling means that some moves has to be played immediately as response to a liberty filling move from the other player. b) You also have the problem of seki. Many nakade problems includes seki as a possibility in the search tree. And there are some common seki patterns involving just a few stones, so in some cases the probability of playing a move should be zero even with few stones. I think the program need to either: 1) Implement proper logic for picking the correct moves 2) Learn from its mistakes, maybe hash every suicidal situation in the playouts played and store statistics. But of course there are always room for any quick and dirty heuristics which actually improves the playing strength. It does not have to be perfect to work well. -Magnus ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] solving the nakade problem
You are right, it is not a perfect solution. I find it attractive though because it is very simple and I think it will work well on a lot of situations. Currently Zoe is losing a lot of games on cgos because it doesnt even know about seki. At least it should be an improvement over what is done in Zoe now. You said Valkyria had a lot of logic about what self-ataris should be allowed. It seems to be usefull, from what I have seen valkyria doesnt seem to have flaws in its life and death understanding, unlike most other MC programs (including mine) - Original Message - From: Magnus Persson [EMAIL PROTECTED] To: computer-go@computer-go.org Sent: Thursday, March 13, 2008 8:57 AM Subject: Re: [computer-go] solving the nakade problem Quoting Ivan Dubois [EMAIL PROTECTED]: Hello, I think there is a very easy and straigthforward solution to the nakade/seki problem, here it is : For moves that are self-atari on a group that contains MORE than 5 stones : Both in the tree and the playouts, strictly forbid them (exactly like you forbid filling an eye). (This is to handle seki and have efficient playouts). For moves that are self-atari on a group that contains LESS than 5 stones : Allow them both in the tree and the playouts. In the playouts, they should be played with a low probability. But they should be played when there is no other move left. (This is to ensure groups with are dead with nakade are eventualy captured in some playouts). What do you think about this solution ? I will probably implement it in Zoe to see if it efficient, unless someone finds a flaw in the logic. Valkyria has a lot of logic about what self-ataris should be allowed or not, and the size of group is part of that. I see two possible flaws in playing the remaining moves self ataris with low probability. a) In some cases the group under attack will appear as alive because the nakade is always always captured in a way that creates a second eye. Just playing all moves with low probability does not mean that the right move is played. Also correct nakade handling means that some moves has to be played immediately as response to a liberty filling move from the other player. b) You also have the problem of seki. Many nakade problems includes seki as a possibility in the search tree. And there are some common seki patterns involving just a few stones, so in some cases the probability of playing a move should be zero even with few stones. I think the program need to either: 1) Implement proper logic for picking the correct moves 2) Learn from its mistakes, maybe hash every suicidal situation in the playouts played and store statistics. But of course there are always room for any quick and dirty heuristics which actually improves the playing strength. It does not have to be perfect to work well. -Magnus ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] solving the nakade problem
Hello, I think there is a very easy and straigthforward solution to the nakade/seki problem, here it is : For moves that are self-atari on a group that contains MORE than 5 stones : Both in the tree and the playouts, strictly forbid them (exactly like you forbid filling an eye). (This is to handle seki and have efficient playouts). For moves that are self-atari on a group that contains LESS than 5 stones : Allow them both in the tree and the playouts. In the playouts, they should be played with a low probability. But they should be played when there is no other move left. (This is to ensure groups with are dead with nakade are eventualy captured in some playouts). What do you think about this solution ? I will probably implement it in Zoe to see if it efficient, unless someone finds a flaw in the logic. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
