Another possibility would be to keep a list of nodes visited in the
"tree" on each playout. In the rare event where the length of this
list exceeds some max game length threshold, go back through the list
looking for repetitions. Mark the first move that led to a repetition
as a loss for the player that made that move. This should eventually
cause the move to be rated so poorly by UCB that it will not be
explored further.
On Jul 11, 2008, at 11:12 AM, Sanghyeon Seo wrote:
2008/7/12 Jason House <[EMAIL PROTECTED]>:
I tracked down a rare hang/crash in my bot and I'm curious how
others handle
this.
I use simple ko state as part of my hash lookup, but I don't use
super ko. I
can't store the whole graph history because then there would be no
transpositions at all. I can't really update legal moves to exclude
super ko
because the super ko legality changes based on how a node is reached.
Fuego source has this interesting comment:
Capture History
As a heuristic fix to the Graph-History-Interaction (GHI) problem,
the hash code also includes a component, that depends on the order, in
which stones were captured.
The idea is to eliminate hashing problems caused by the same
position reached at different level in the search, or recapture
is legal in one branch and illegal in another.
It is not a complete solution to the GHI problem.
--
Seo Sanghyeon
_______________________________________________
computer-go mailing list
[email protected]
http://www.computer-go.org/mailman/listinfo/computer-go/
Peter Drake
http://www.lclark.edu/~drake/
_______________________________________________
computer-go mailing list
[email protected]
http://www.computer-go.org/mailman/listinfo/computer-go/
