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.
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.
Mark
_______________________________________________
computer-go mailing list
[email protected]
http://www.computer-go.org/mailman/listinfo/computer-go/
