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
> [email protected]
> http://www.computer-go.org/mailman/listinfo/computer-go/
>
--
=========================================================
Olivier Teytaud (TAO-inria) [email protected]
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
[email protected]
http://www.computer-go.org/mailman/listinfo/computer-go/
