On 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.
That was my preference too, but...
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.
That trick only works when your playout is non-deterministic. Outside
the search tree, things are non-deterministic and cycles are easy to
break or ignore. Inside the search tree it isn't that easy. If no
cached data is updated from an aborted search, UCT will walk the tree
the same way it did for the last playout.
When the cycle is *inside* the search tree, this means another
infinite/aborted playout. The abortted playout trick would cause the
bot to cycle uselessly until the game takes another path.
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/
