Hi, On 11:24 Thu 15 Jan , Mark Boon wrote: > > On Jan 15, 2009, at 10:47 AM, Daniel Waeber wrote: > > > Thanks you. I think that I understand it now :) > > > > On 23:21 Wed 14 Jan , Mark Boon wrote: > >> You have to understand that the 'start' variable really starts at the > >> root from the position for which we do the search. So all the moves > >> 'below' the playoutNode are also taken into account. The check in the > >> earlier part "if (_colorMap[moveXY]==0)" makes sure there's no move > >> between the playoutNode and the n.move as you call it. > > > > Ah, yes, I did not get the meaning of start right. But still I think > > you > > have to incrementally add values to the maps as you go down the tree. > > But it does that. This happens when playoutNode is set to its parent > and the AMAF values are added again (now for the other color) until > the root is reached.
yes, but the weight/color maps stay the same for all updated nodes. I think the first playoutNode (the one most deep inside the tree) only should get amaf values for the random playout, the next one form random playout + from the first playoutNode ... and the root node amaf values form all the nodes. I attached code for what I would do, but had no time to test it. > > I think there's a problem with caputres/ko-fights inside the tree. > > All nodes after the capture should get the amaf color/value for the > > stones put there after the capture and not the value of the stones > > that > > were put there and captured. > > > > Most likely I missed a little piece of code again, but hey, perhaps > > its > > a real bug. > > I did stop to think about ko and 'ishi no shita' (something like > 'playing under the stones') a little bit but couldn't come to an > immediate conclusion what would be the best thing to do. So I decided > to leave it as it is. You didn't miss any little piece of code there. > Maybe there's room for improvement in case of ko, but my guess is the > difference will be minimal at best. If you find it does make a big > difference everyone here will be delighted to hear it. > > Given how it's performing I doubt there are major problems with my > AMAF-RAVE implementation. regards wabu > > Mark >
diff --git a/TesujiRefBot/source/tesuji/games/go/reference/search/MonteCarloTreeSearch.java b/TesujiRefBot/source/tesuji/games/go/reference/search/MonteCarloTreeSearch.java index 5e47e00..ee650e1 100644 --- a/TesujiRefBot/source/tesuji/games/go/reference/search/MonteCarloTreeSearch.java +++ b/TesujiRefBot/source/tesuji/games/go/reference/search/MonteCarloTreeSearch.java @@ -566,6 +566,7 @@ public class MonteCarloTreeSearch<MoveType extends Move> TreeNode<MonteCarloTreeSearchResult<MoveType>> node = getNodeToExpand(_rootNode, _searchAdministration); TreeNode<MonteCarloTreeSearchResult<MoveType>> playoutNode = node; + int start = _searchAdministration.getMoveStack().getSize(); // begin at playoutNode if (node != null) { @@ -580,7 +581,6 @@ public class MonteCarloTreeSearch<MoveType extends Move> { IntStack playoutMoves = _searchAdministration.getMoveStack(); byte color = _monteCarloAdministration.getColorToMove(); - int start = _monteCarloAdministration.getMoveStack().getSize(); int end = playoutMoves.getSize(); double weight = 1.0; double weightDelta = 1.0 / (end - start + 1); // Michael Williams' idea to use decreasing weights @@ -613,6 +613,13 @@ public class MonteCarloTreeSearch<MoveType extends Move> if (_colorMap[xy]==color) result.increaseVirtualPlayouts(_weightMap[xy]*score,_weightMap[xy]); } + // add the move to the maps now + GoMove move = (GoMove) playoutNode.getContent().getMove(); + int xy = move.getXY(); + byte col = move.getColor(); + _colorMap[xy] = col; + _weightMap[xy] = 1.0; //TODO: handle weight + playoutNode = playoutNode.getParent(); } }
_______________________________________________ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/