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. 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. > That is, if I understand you correctly. Because I'm not quite sure > what you mean by 'finding all these nodes n'. This is not a sub-set of > RAVE as I understand it. What you see in the code is the accumulation > of the AMAF values after each playout. The RAVE value is calculated > using these values when comparing move-candidates, which is in an > altogether different place. (The MonteCarloTreeSearchResult class in > my project). > > I'm afraid I haven't made things much clearer for you. The problem is that I was confused, but now, as I understand it, all your and all the other comments suddenly make sense ;) > Mark Thank again, wabu _______________________________________________ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
