RE: [computer-go] Conflicting RAVE formulae
I created the joseki database for the DOS program when typical computers had 1 MByte of memory. It's stored in a highly compressed format using 10 bits per node in the DAG (each node has x and y coordinate and an indication of the type of joseki: good/bad/trick/followup, and an indication if it makes the position symmetric). The code to decompress it is rather complex and I wrote it 20 years ago, so converting to patterns would take quite a bit of effort. I think spending that time on making playouts smarter would help program strength more. I converted the fuseki database from a tree to a big hash table of patterns for version 12, and it took way more effort than I expected when I started. From: computer-go-boun...@computer-go.org [mailto:computer-go-boun...@computer-go.org] On Behalf Of Brian Sheppard Sent: Thursday, September 17, 2009 10:36 AM To: computer-go@computer-go.org Subject: [computer-go] Conflicting RAVE formulae >Many Faces has a joseki database with about 64000 corner positions. It's >stored as a DAG, not a set of patterns, so it can't find transpositions. Just curious: why don't you convert the DAG into patterns at program initialization? ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
RE: [computer-go] rave and patterns
Pretty close. Rave is accumulated for every trial (I don't want to throw away useful information). N depends on the board size. K > N and the ratio is not fixed. I use progressive widening, and I'm curious what the widening formula is for other programs, or how slowly it increases. From: computer-go-boun...@computer-go.org [mailto:computer-go-boun...@computer-go.org] On Behalf Of Brian Sheppard Sent: Thursday, September 17, 2009 11:10 AM To: computer-go@computer-go.org Subject: [computer-go] rave and patterns Olivier and David both: a huge "thank you" for sharing your secrets. I think David makes clear that his large patterns apply only to the UCT process, and then only after a significant number of trials are reached. I gather that the lifecycle of a node is something like this in MFGO: 1) When a node is first created, search only the standard playout policy. 2) After N trials, begin accumulating RAVE statistics. (IIRC, David said that N = 4.) 3) On the K-th trial, use the Many Faces knowledge base to bias RAVE statistics. David, do I have this right? And is K > N? Or K >> N? In Pebbles, the process is slightly different: 1) When a node is first created, search only the standard playout policy. 2) RAVE data accumulates from the first trial. (Pebbles is slow. :-) ) 3) When that node has its first loss, then apply a progressive widening policy. In Pebbles, BTW, the progressive widening policy is rudimentary, consisting mostly of distance and 3x3 pattern. What is the lifecycle of a node in MoGo? Another question about MoGo: David makes clear that large patterns (and presumably joseki) apply only to the UCT process. Does MoGo apply such knowledge in playouts? Thanks again. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Dead stones in human-bot games
Got it -- thanks! Peter Drake http://www.lclark.edu/~drake/ On Sep 17, 2009, at 3:55 PM, Jason House wrote: This comes up from time to time on this list. Rated games require the human to accept what the bot says (but can undo to continue play). In free games the bots must accept what the human says. Sent from my iPhone On Sep 17, 2009, at 5:27 PM, terry mcintyre wrote: Is there no way for the bot to dispute the other player's decision? I recall something of the sort in human-to-human play -- both have to agree before the scoring phase. I do not know whether the KGS API works the same way. Terry McIntyre "And one sad servitude alike denotes The slave that labours and the slave that votes" -- Peter Pindar From: Peter Drake To: Computer Go Sent: Thursday, September 17, 2009 1:52:07 PM Subject: [computer-go] Dead stones in human-bot games Orego has been doing well in 9x9 games on KGS, using the fast time controls of this weekend's upcoming tournament. I even improved the endgame behavior a bit: Orego will pass if (a) the opponent has passed first, and (b) after removing Orego's dead stones, but not the opponent's, Orego still wins. This means that Orego won't always play until there are no legal moves. I looked at one of the lost games (attached), and found that (if I'm reading this correctly) the human won simply by marking all of Orego's (white) stones dead. Do bots automatically defer to humans when there are disputes? Isn't there supposed to be a cleanup phase? Would it be the same in a rated game? 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/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Dead stones in human-bot games
This comes up from time to time on this list. Rated games require the human to accept what the bot says (but can undo to continue play). In free games the bots must accept what the human says. Sent from my iPhone On Sep 17, 2009, at 5:27 PM, terry mcintyre wrote: Is there no way for the bot to dispute the other player's decision? I recall something of the sort in human-to-human play -- both have to agree before the scoring phase. I do not know whether the KGS API works the same way. Terry McIntyre "And one sad servitude alike denotes The slave that labours and the slave that votes" -- Peter Pindar From: Peter Drake To: Computer Go Sent: Thursday, September 17, 2009 1:52:07 PM Subject: [computer-go] Dead stones in human-bot games Orego has been doing well in 9x9 games on KGS, using the fast time controls of this weekend's upcoming tournament. I even improved the endgame behavior a bit: Orego will pass if (a) the opponent has passed first, and (b) after removing Orego's dead stones, but not the opponent's, Orego still wins. This means that Orego won't always play until there are no legal moves. I looked at one of the lost games (attached), and found that (if I'm reading this correctly) the human won simply by marking all of Orego's (white) stones dead. Do bots automatically defer to humans when there are disputes? Isn't there supposed to be a cleanup phase? Would it be the same in a rated game? 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/
Re: [computer-go] Dead stones in human-bot games
Is there no way for the bot to dispute the other player's decision? I recall something of the sort in human-to-human play -- both have to agree before the scoring phase. I do not know whether the KGS API works the same way. Terry McIntyre "And one sad servitude alike denotes The slave that labours and the slave that votes" -- Peter Pindar From: Peter Drake To: Computer Go Sent: Thursday, September 17, 2009 1:52:07 PM Subject: [computer-go] Dead stones in human-bot games Orego has been doing well in 9x9 games on KGS, using the fast time controls of this weekend's upcoming tournament. I even improved the endgame behavior a bit: Orego will pass if (a) the opponent has passed first, and (b) after removing Orego's dead stones, but not the opponent's, Orego still wins. This means that Orego won't always play until there are no legal moves. I looked at one of the lost games (attached), and found that (if I'm reading this correctly) the human won simply by marking all of Orego's (white) stones dead. Do bots automatically defer to humans when there are disputes? Isn't there supposed to be a cleanup phase? Would it be the same in a rated game? 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] Dead stones in human-bot games
Orego has been doing well in 9x9 games on KGS, using the fast time controls of this weekend's upcoming tournament. I even improved the endgame behavior a bit: Orego will pass if (a) the opponent has passed first, and (b) after removing Orego's dead stones, but not the opponent's, Orego still wins. This means that Orego won't always play until there are no legal moves. I looked at one of the lost games (attached), and found that (if I'm reading this correctly) the human won simply by marking all of Orego's (white) stones dead. Do bots automatically defer to humans when there are disputes? Isn't there supposed to be a cleanup phase? Would it be the same in a rated game? Orego-jika.sgf Description: Binary data 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: [SPAM] [computer-go] rave and patterns
> David, do I have this right? And is K > N? Or K >> N?
This is somewhat similar in MoGo, with N=5 and K=10 nearly (I say
"nearly" because we have two levels of go expertise, the second being
much more expensive and not yet operationel, so we have in fact K1 and
K2).
> In Pebbles, BTW, the progressive widening policy is rudimentary, consisting
> mostly of distance and 3x3 pattern.
I think that "progressive widening" means that you add arms one at a time
(precisely, the n^{th} simulation chooses between the f(n) first
possible nodes for the heuristic (the heuristic might be Rave,
patterns,...), whereas
"progressive unpruning" means that you combine linearly the two values
(e.g. the UCT value and the heuristic value), the second one
decreasing e.g. linearly. For us "progressive unpruning" is much
better than "progressive widening" which might add a child node
whenever the first nodes have success rate 1. We have in fact a much
more complicated formula than that,
but I don't know to which extent our terms are general.
> joseki) apply only to the UCT process. Does MoGo apply such knowledge in
> playouts?
No, in the current version. We have an experimental version in which
the knowledge has a strong impact on the playouts, and this looks nice
when we apply mogo to some particular situations, but on average it
makes mogo weaker - this is very disappointing because the approach
was very appealing and we've believed in it when we have seen that
some typical situations in which mogo is weak were now correctly
considered by mogo :-(
Best regards,
Olivier
___
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] rave and patterns
Olivier and David both: a huge "thank you" for sharing your secrets. I think David makes clear that his large patterns apply only to the UCT process, and then only after a significant number of trials are reached. I gather that the lifecycle of a node is something like this in MFGO: 1) When a node is first created, search only the standard playout policy. 2) After N trials, begin accumulating RAVE statistics. (IIRC, David said that N = 4.) 3) On the K-th trial, use the Many Faces knowledge base to bias RAVE statistics. David, do I have this right? And is K > N? Or K >> N? In Pebbles, the process is slightly different: 1) When a node is first created, search only the standard playout policy. 2) RAVE data accumulates from the first trial. (Pebbles is slow. :-) ) 3) When that node has its first loss, then apply a progressive widening policy. In Pebbles, BTW, the progressive widening policy is rudimentary, consisting mostly of distance and 3x3 pattern. What is the lifecycle of a node in MoGo? Another question about MoGo: David makes clear that large patterns (and presumably joseki) apply only to the UCT process. Does MoGo apply such knowledge in playouts? Thanks again. ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] Conflicting RAVE formulae
>Many Faces has a joseki database with about 64000 corner positions. It's >stored as a DAG, not a set of patterns, so it can't find transpositions. Just curious: why don't you convert the DAG into patterns at program initialization? ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
