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]
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
Since the tree is of finite size, you will eventually get to the
nondeterministic part of the playout. The moves here will probably
finish the playout (one way or another) before hitting the maximum
move threshold, so the playout will not be aborted but will update the
tree.
On Jul 11,
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
Do you always check it? Would it be faster to hold off on this check
until you realize that you're in a cycle?
On Jul 11, 2008, at 12:06 PM, John Fan wrote:
I guess you missed my message.
I solved this by comparing the current node with its ancestors in
the path. On each walking down the
