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/
