Re: [computer-go] ICML paper
David Silver wrote: > Hi all, > > Our paper "Sample-Based Learning and Search with Permanent and > Transient Memories" has been accepted for publication at ICML 2008. > Once again, I would really appreciate any feedback or comments on the > paper. This is nit-picky, but CGOS is supposed to mean (C)omputer (G)(O) (S)erver, however don't change the paper, I like what you have better! Other papers also use this same acronym, which is more descriptive and so I think I'll just keep it. - Don > > http://www.cs.ualberta.ca/~silver/research/publications/files/dyna2.pdf > > ICML is a technical conference on machine learning, and the paper > assumes some familiarity with machine learning terminology. Having > said that, I hope that the main ideas are understandable by everyone > on this list! In particular I've heard several people ask questions like: > > -How can we generalise between different positions during search? > -How can we learn "on the fly" about the value of different patterns? > -How can we combine learned knowledge with search? > -Are there more efficient algorithms than Monte-Carlo for updating the > value of states or patterns? > -What's so special about UCT? Can we get similar or better performance > by using other sample-based search algorithms? > > The Dyna-2 architecture described in this paper provides an approach > for answering these questions. > Hopefully this will pique your interest enough to read the paper :-) > > Thanks! > -Dave > > ___ > 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] Greedy search vs UCT
I have checked if there is a difference for Valkyria in using confidence bounds or just greedily search the move with the highest winrate. This is Valkyria 3.2.0 using 512 simulations per move against GnuGo 3.7.10. UCT_K Winrate SERR 0 58.82.2 (greedy) 0.0156.82.2 0.1 60.92.2 0.5 54.22.2 1 50.62.2 As you can see up to uct_k = 0.1, the winrate aginst gnugo is more or less constant (500 games was played for each value of uct_k) and then it declines. So although 0.1 was best I cannot claim that it is better than a plain greedy search. I will repeat this using 4 times as many simulations per move. The search sensitivity to uct_k may depend on how deep the tree is searched. -Magnus ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
RE: [computer-go] Greedy search vs UCT
What level for gnugo 3.7.10? > -Original Message- > From: [EMAIL PROTECTED] [mailto:computer-go- > [EMAIL PROTECTED] On Behalf Of Magnus Persson > Sent: Thursday, April 24, 2008 8:28 AM > To: computer-go@computer-go.org > Subject: [computer-go] Greedy search vs UCT > > I have checked if there is a difference for Valkyria in using > confidence bounds or just greedily search the move with the highest > winrate. This is Valkyria 3.2.0 using 512 simulations per move against > GnuGo 3.7.10. > > UCT_K Winrate SERR > 0 58.82.2 (greedy) > 0.01 56.82.2 > 0.1 60.92.2 > 0.5 54.22.2 > 1 50.62.2 > > As you can see up to uct_k = 0.1, the winrate aginst gnugo is more or > less constant (500 games was played for each value of uct_k) and then > it declines. > > So although 0.1 was best I cannot claim that it is better than a plain > greedy search. > > I will repeat this using 4 times as many simulations per move. The > search sensitivity to uct_k may depend on how deep the tree is > searched. > > -Magnus > > > ___ > 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] Greedy search vs UCT
I run it with gnugo3.7.10.exe --mode gtp --chinese-rules --score aftermath --capture-all-dead --positional-superko Which is the default level which I do not know what it is. -Magnus Quoting David Fotland <[EMAIL PROTECTED]>: What level for gnugo 3.7.10? ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] scalability with the quality of play-outs.
On Tue, Apr 22, 2008 at 4:23 PM, Don Dailey <[EMAIL PROTECTED]> wrote: > Here is what I'm going to do: > > I will take an open source chess program, Toga, and run a multi-round > robin between 7 versions from fixed depth 1 to fixed depth 7. Two > versions of Toga at these 7 levels where one version has pawn structure, > king safety, and passed pawns turned off. ... I am not familiar with chess programming, and I haven't been paying complete attention to this discussion, but I thought that I should comment on this. Without any background knowledge, I would expect that the bits of "knowledge" that you are turning off are present in the starting program largely because they do scale well. Furthermore, if your claim is: "a chess program with a better evaluation function improves MORE with increasing depth than one with a lesser evaluation function" ...then I don't see how you will make much progress at Settling the Matter with this study, since all it will show (at best) is that there exists one pair of evaluation functions that match your rule. A better approach, to my mind, would be to test a wide variety of different evaluation functions. As I understand it, you want to show that there is a strong correlation between their relative playing ability at (widely) different depths. Ideally, you should include as many evaluation functions as you can manage, and ones that are as different from each other as possible. Also, you possibly might want to also combine them with multiple, different kinds of pruning/searching/whatever-else-goes-into-a-chess-engine-that-isn't-considered-evaluation. This would show that you are exposing the general rule, rather than just an example of that rule. Am I misunderstanding your claim? Of course, that would be quite a bit of work, that I am suggesting. Perhaps a modest step in this direction would be to run tournaments between 3 versions of Toga, each with only one enabled feature out of the three that you identify. (Or perhaps two. However, avoid including combinations where one version has features that are a subset of another. This may help to mitigate objections such as my initial one above.) On the plus side, though, I see no reason to run any depths other than 1 and 7, since I think that you just want the rank correlation between two different depths. Weston ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] 19x19 server
I noticed there is not much 19x19 activity recently. My copies of Many Faces died and didn't notice, probably some time ago. I restarted them today. If they stop again, just send me e-mail and I'll start them. They have a dedicated machine in the corner, so if windows update forces a reboot, I don't notice it. David ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] Test position set for MC programs
On Problem 125, sounds like B2 is also a right move. On Wed, Apr 23, 2008 at 3:33 PM, Gunnar Farnebäck <[EMAIL PROTECTED]> wrote: > Yamato wrote: > > Thanks Gian-Carlo, Gunnar. > > > > Current list of results. > > > > GNU Go 3.7.12 level 0 : 24/50 > > GNU Go 3.7.12 level 10 : 34/50 > > GNU Go 3.7.12 level 15 : 37/50 > > GNU Go 3.7.12 mc, 1k : 30/50 > > GNU Go 3.7.12 mc, 10k : 31/50 > > GNU Go 3.7.12 mc, 100k : 38/50 > > GNU Go 3.7.12 mc, light, 1k: 33/50 > > GNU Go 3.7.12 mc, light, 10k : 30/50 > > GNU Go 3.7.12 mc, light, 100k : 25/50 > > GNU Go 3.7.12 mc, mogo, 1k : 34/50 > > GNU Go 3.7.12 mc, mogo, 10k: 33/50 > > GNU Go 3.7.12 mc, mogo, 100k : 35/50 > > Leela 0.3.14, 1k : 19/50 > > Leela 0.3.14, 10k : 28/50 > > Leela 0.3.14, 100k : 36/50 > > Zen 1.5, 1k: 19/50 > > Zen 1.5, 10k : 22/50 > > Zen 1.5, 100k : 24/50 > > > > Leela seems to have good scalability. 36/50 passes is fine. > > The results of GNU Go are a bit irregular because of its hybrid > > strategy. If GNU Go could run on the MC only mode, it might be more > > interesting, I guess. > > Ok, I patched out the contributions from normal move generation in the > final move selection (but there's still some influence on UCT tree > move ordering), giving this list: > >Only MC > GNU Go 3.7.12 level 0 : 24/50- > GNU Go 3.7.12 level 10 : 34/50- > GNU Go 3.7.12 level 15 : 37/50- > GNU Go 3.7.12 mc, 1k : 30/50 14/50 > GNU Go 3.7.12 mc, 10k : 31/50 29/50 > GNU Go 3.7.12 mc, 100k : 38/50 35/50 > GNU Go 3.7.12 mc, light, 1k: 33/507/50 > GNU Go 3.7.12 mc, light, 10k : 30/50 14/50 > GNU Go 3.7.12 mc, light, 100k : 25/50 22/50 > GNU Go 3.7.12 mc, mogo, 1k : 34/50 14/50 > GNU Go 3.7.12 mc, mogo, 10k: 33/50 21/50 > GNU Go 3.7.12 mc, mogo, 100k : 35/50 34/50 > > /Gunnar > > ___ > 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] scalability with the quality of play-outs.
Weston Markham wrote: > On Tue, Apr 22, 2008 at 4:23 PM, Don Dailey <[EMAIL PROTECTED]> wrote: > >> Here is what I'm going to do: >> >> I will take an open source chess program, Toga, and run a multi-round >> robin between 7 versions from fixed depth 1 to fixed depth 7. Two >> versions of Toga at these 7 levels where one version has pawn structure, >> king safety, and passed pawns turned off. >> > ... > > I am not familiar with chess programming, and I haven't been paying > complete attention to this discussion, but I thought that I should > comment on this. Without any background knowledge, I would expect > that the bits of "knowledge" that you are turning off are present in > the starting program largely because they do scale well. > Not likely. Programmers put knowledge into chess program specifically to make them play stronger.I don't know of any programmer who tries to hand tailor knowledge like this specifically to make is scale better. > Furthermore, if your claim is: > > "a chess program with a better evaluation function improves MORE with > increasing depth than one with a lesser evaluation function" > > ...then I don't see how you will make much progress at Settling the > Matter with this study, since all it will show (at best) is that there > exists one pair of evaluation functions that match your rule. > My plan is to do the study, document if fully so that it can be verified by anyone who wants to, and let people draw their own conclusions. If they don't agree with MY conclusions they can come to their own and perhaps back it up with their own study. > A better approach, to my mind, would be to test a wide variety of > different evaluation functions. As I understand it, you want to show > that there is a strong correlation between their relative playing > ability at (widely) different depths. Ideally, you should include as > many evaluation functions as you can manage, and ones that are as > different from each other as possible. Also, you possibly might want > to also combine them with multiple, different kinds of > pruning/searching/whatever-else-goes-into-a-chess-engine-that-isn't-considered-evaluation. > This would show that you are exposing the general rule, rather than > just an example of that rule. Am I misunderstanding your claim? > I am satisfied if I can show that it's possible to create a scalable evaluation function or in your terminology an example of the rule.If my very first test shows the effect, it would be pretty unreasonable to conclude that I just happened to get lucky. A much more reasonable conclusion would be that it's a common feature of many good evaluation terms and that it's not difficult to produce such functions. Your original assertion that all I'm proving is that this pair of functions exhibits this effect, may be technically true, but not reasonable in my opinion. Using different pruning and searching rules is not necessary. It's indisputable that different search heuristics scale better, there is nothing to prove. > Of course, that would be quite a bit of work, that I am suggesting. > Yes, and I'm not really into this that much, I'm only trying to prove something (empirically) that most chess programmers already know anyway but was never documented to my knowledge. > Perhaps a modest step in this direction would be to run tournaments > between 3 versions of Toga, each with only one enabled feature out of > the three that you identify. (Or perhaps two. However, avoid > including combinations where one version has features that are a > subset of another. This may help to mitigate objections such as my > initial one above.) On the plus side, though, I see no reason to run > any depths other than 1 and 7, since I think that you just want the > rank correlation between two different depths. > Yes, I considered only running these 2 levels but I'm also interested in the general curve and I think it's more robust to test against some opponent weaker and stronger and not just one. - Don > Weston > ___ > 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] Test position set for MC programs
When you guys get those problems corrected, can you send an updated version? - Don John Fan wrote: > On Problem 125, sounds like B2 is also a right move. > > On Wed, Apr 23, 2008 at 3:33 PM, Gunnar Farnebäck <[EMAIL PROTECTED]> > wrote: > > >> Yamato wrote: >> >>> Thanks Gian-Carlo, Gunnar. >>> >>> Current list of results. >>> >>> GNU Go 3.7.12 level 0 : 24/50 >>> GNU Go 3.7.12 level 10 : 34/50 >>> GNU Go 3.7.12 level 15 : 37/50 >>> GNU Go 3.7.12 mc, 1k : 30/50 >>> GNU Go 3.7.12 mc, 10k : 31/50 >>> GNU Go 3.7.12 mc, 100k : 38/50 >>> GNU Go 3.7.12 mc, light, 1k: 33/50 >>> GNU Go 3.7.12 mc, light, 10k : 30/50 >>> GNU Go 3.7.12 mc, light, 100k : 25/50 >>> GNU Go 3.7.12 mc, mogo, 1k : 34/50 >>> GNU Go 3.7.12 mc, mogo, 10k: 33/50 >>> GNU Go 3.7.12 mc, mogo, 100k : 35/50 >>> Leela 0.3.14, 1k : 19/50 >>> Leela 0.3.14, 10k : 28/50 >>> Leela 0.3.14, 100k : 36/50 >>> Zen 1.5, 1k: 19/50 >>> Zen 1.5, 10k : 22/50 >>> Zen 1.5, 100k : 24/50 >>> >>> Leela seems to have good scalability. 36/50 passes is fine. >>> The results of GNU Go are a bit irregular because of its hybrid >>> strategy. If GNU Go could run on the MC only mode, it might be more >>> interesting, I guess. >>> >> Ok, I patched out the contributions from normal move generation in the >> final move selection (but there's still some influence on UCT tree >> move ordering), giving this list: >> >>Only MC >> GNU Go 3.7.12 level 0 : 24/50- >> GNU Go 3.7.12 level 10 : 34/50- >> GNU Go 3.7.12 level 15 : 37/50- >> GNU Go 3.7.12 mc, 1k : 30/50 14/50 >> GNU Go 3.7.12 mc, 10k : 31/50 29/50 >> GNU Go 3.7.12 mc, 100k : 38/50 35/50 >> GNU Go 3.7.12 mc, light, 1k: 33/507/50 >> GNU Go 3.7.12 mc, light, 10k : 30/50 14/50 >> GNU Go 3.7.12 mc, light, 100k : 25/50 22/50 >> GNU Go 3.7.12 mc, mogo, 1k : 34/50 14/50 >> GNU Go 3.7.12 mc, mogo, 10k: 33/50 21/50 >> GNU Go 3.7.12 mc, mogo, 100k : 35/50 34/50 >> >> /Gunnar >> >> ___ >> 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] Test position set for MC programs
John Fan wrote: >On Problem 125, sounds like B2 is also a right move. B:B2, W:B1, B:C1, W:A2, B:A1, W:C2, B:A3, W:D1. Black seems to cannot win this ko. -- Yamato ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
