The go expertise in Many Faces includes 1901 big patterns. These are input by myself, and are up to 8x8. They include don't cares, such as (white or empty), so are equivalent to far more patterns that just have stone positions. The patterns are also qualified with the strength of the groups involved. Each pattern has local move tree attached, with a total of about 50900 moves across all patterns. So I suppose you could consider this to be a collection of hundreds of thousands of equivalent patterns.
eWBxxxxx eeeexxxx eWeeWxxx eeeeXxxx AN21<AD,31<AD,31N, 32B8;33W7;22B5.34W7:14W7.32W7. This is an example pattern. I don't edit this format, I have a graphical pattern editor. BWe are colors. x is don't care. X marks the corner of the pattern. 21<AD means the stone at 2,1 is not dead. 31N means the stone at 3,1 is not tactically threatened. There are about a dozen qualifiers that can be specified. The last line is the move tree, with a fairly obvious format. The don't care point allow the pattern to be any shape that fits in 8x8. 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. Many Faces has a fuseki database organized as a big rotation-invariant hash table with all positions from about 30,000 professional games. A great deal of expertise has to do with attacking and defending weak groups. It does extensive analysis of eye shapes and connections with local lookahead. This move generator is very slow so I only use it to bias moves in the UCT tree after many visits. I don't think of Many Faces as having a big database of patterns since there is so much code, and only 1900 general patterns, but I think in comparison with other strong programs you might consider it to have a large pattern database. Many Faces uses RAVE too. David From: computer-go-boun...@computer-go.org [mailto:computer-go-boun...@computer-go.org] On Behalf Of Olivier Teytaud Sent: Monday, September 14, 2009 1:23 PM To: computer-go Subject: Re: [SPAM] [computer-go] Conflicting RAVE formulae Just a small comment: adding one more term taking into account big patterns (big = more than 3x3) provide a huge improvement in 19x19. In my humble opinion there is more to win with adding such a term than by modifying the formula. Of course, it implies collecting a database of SGF files and extracting from it a database of patterns with their values :-) In 19x19, databases of big patterns (as in CrazyStone, Mango, Zen, I think, and for sure in MoGo) are really great. I don't know to which extent RAVE is still useful when you have patterns in 19x19. In 9x9, I'm sure that we have no database of patterns which replaces RAVE values, but perhaps it's because we have no database of patterns specialized for 9x9. Or perhaps big patterns in 9x9 don't work :-) Also I don't know to which extent go expertise can replace big databases of patterns; I guess that in manyFaces there's no such big database of patterns (I'm not sure of that), but much more Go expertise. Perhaps Zen has both ? MoGo has RAVE+patterns+go expertise, but the go expertise is probably smaller than in ManyFaces and Zen. In Fuego, I guess there's go expertise and rave values, but no database of patterns ? Sorry for people working on Fuego, Zen, Mango, CrazyStone, ManyFaces if I have made mistakes about their programs :-) Best regards, Olivier Gelly and Silver ("Combining Online and Offline Knowledge in UCT", section 6) give this formula for the weight given to RAVE values (as opposed to the direct MC values): sqrt(k / (3*n(s) + k)) Here, k is a constant and n(s) is the number of playouts through state s. Clearly, as the number of playouts increases, this approaches zero. Hembold and Parker-Wood ("All-Moves-As-First Heuristics in Monte-Carlo Go") site the Gelly and Silver paper, but give a different formula! Adjusting for notation, they use: (k - n(s)) / k, or 0 if this expression is negative This also converges toward (and then sticks at) zero, but it it not the same formula. Why are they different? Does it matter? Is there an explanation anywhere for Gelly and Silver's more elaborate formula? Is there anything wrong with k / (n(s) + k)? On a related note, in a message on this list, David Silver gives a newer formula: http://computer-go.org/pipermail/computer-go/2009-May/018251.html Was this ever published? (Orego is using this newer formula, and it appears to work well.) 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/ -- ========================================================= Olivier Teytaud (TAO-inria) olivier.teyt...@inria.fr Tel (33)169154231 / Fax (33)169156586 Equipe TAO (Inria-Futurs), LRI, UMR 8623(CNRS - Universite Paris-Sud), bat 490 Universite Paris-Sud 91405 Orsay Cedex France (one of the 56.5 % of french who did not vote for Sarkozy in 2007)
_______________________________________________ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
