I think we mean the same. So when black plays at a1 first we count it for
black everywhere but never for white. Correct?
The question is, if both black and white play a1 - because there were
captures in the middle - whether both of them will update a1 in some of
their nodes. I believe so.
Ah yes, the UCB term. I’ve now added it. I dimly remember now that Pachi
doesn’t use it but yes I’ve now added it. And I’m not sure I understand you
other comment. My nodes store the visits/etc, the move made, and references
to all children.
I've checked and that's with Pachi/Michi do too. And it's the closest to
the MCTS diagrams and explanations that are published around. But
instead you could just have the information on transitions from a state,
and not wins/visits of the state per se. I'm not very familiar with
Pachi (I couldn't find how it implements a transpositions table, or how
it prunes it with memory safety).
I use a structure with
color
visits[19][19]
wins[19][19]
amaf_visits[19][19]
amaf_wins[19][19]
etc
They are very similar, but my node information doesn't need to consult
the transpositions table or follow points to select the next play. On
the other hand sequences of play that arrive on the same node have the
exact same "quality" regardless of sequence of play in Pachi, where in
my program the sequences of play only "unite" when following that state
forward.
I don't know if this difference is very small or if I'm forgetting
something important. Maybe Pachi implements discovering if a state has
already been expanded in a very efficient way.
I don't know how other programs do it, but instinctively, if you started
by implementing a non-UCT MCTS algorithm, the information you kept would
be just the initial state and statistics on the transitions, so my train
of thought seems (to me) the logical follow up.
Gonçalo F.
_______________________________________________
Computer-go mailing list
[email protected]
http://computer-go.org/mailman/listinfo/computer-go
