I had the same issue in UCT tree. What I did is to check if the current node is a ko move, then compare it with its latest 6 ancestors. If any match is found, then consider the move is a loss. So it cuts off the infinite loop.
On Fri, Jul 11, 2008 at 12:08 PM, Peter Drake <[EMAIL PROTECTED]> wrote: > My sense is that most programs ignore superko except for checking right > before a "real" move (as opposed to a playout move) is played. > > The way out of the infinite loop is to set a maximum number of moves in a > playout; abort the playout if you reach this threshold. > > > On Jul 11, 2008, at 9:03 AM, Jason House wrote: > > 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. >> >> In particular, a deterministic algorithm like UCT can get caught in an >> infinite loop. My random playouts may take a bit longer from super ko, but >> it gets quickly resolved. >> >> Sent from my iPhone >> _______________________________________________ >> computer-go mailing list >> computer-go@computer-go.org >> http://www.computer-go.org/mailman/listinfo/computer-go/ >> > > Peter Drake > http://www.lclark.edu/~drake/ <http://www.lclark.edu/%7Edrake/> > > > > > _______________________________________________ > computer-go mailing list > computer-go@computer-go.org > http://www.computer-go.org/mailman/listinfo/computer-go/ >
_______________________________________________ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
