[computer-go] cotsen open will be on september 20-21'st
The dates for the Cotsen Go Tournament have been decided. The tournament will be held on September 20 and 21 at the Tom Bradley International Hall on the UCLA campus. This is the same location where the Toyota Denso North American Oza was held this past January. thanks --- vice-chair http://ocjug.org/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] cotsen open will be on september 20-21'st
In message [EMAIL PROTECTED], Ray Tayek [EMAIL PROTECTED] writes The dates for the Cotsen Go Tournament have been decided. The tournament will be held on September 20 and 21 at the Tom Bradley International Hall on the UCLA campus. This is the same location where the Toyota Denso North American Oza was held this past January. Will it include a Computer Go event this year? Nick -- Nick Wedd[EMAIL PROTECTED] ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Graph history interaction
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/
Re: [computer-go] Graph history interaction
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/
Re: [computer-go] Graph history interaction
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, at 9:39 AM, Jason House wrote: 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. Peter Drake http://www.lclark.edu/~drake/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Graph history interaction
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 computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Graph history interaction
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 tree, I pass the list of nodes in the same path. Then I check whether the current node already appear in the path. If yes, I assign a loss there. To speed it up, I only check the current node against 6 nodes before it. It is not perfect or accurate solution for the issue, but it solves the problem at hand. On Fri, Jul 11, 2008 at 12:23 PM, John Fan [EMAIL PROTECTED] wrote: 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/ ___ 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/ Peter Drake http://www.lclark.edu/~drake/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
