Although most of my time has been eaten up by implementing/improving
some general framework parts I did get a chance to play a bit with a
simple UCT search. Some things that I found puzzled me a bit and I
hoped someone had an explanation or similar experiences.
I implemented a very basic
Hi Mark,
You should run a lot more test games. The 95% confidence interval on the
result is at least sqrt(1/num_games), so you need 400 or more games to know
the win rate within 5%. I've seen many anomalous win rates when I used to
test with 20 games. Now I use 200 games minimum, and I try
Please correct me if I'm wrong, but I thought:
Only once you combine the two components does the influence of UCB1 and
UCB1-tuned become less obvious. If you look at just the RAVE success ratio
component, or just the success ratio component, I believe the UCB1-Tuned
formula is still present.
On Feb 5, 2008 2:08 PM, David Fotland [EMAIL PROTECTED] wrote:
It think many programs run several simulations through a node before
allocating the children. I can see how this saves memory, but then how do
you save the RAVE information from the early simulations?
For RAVE, after doing a sim
As promised, to answer Rémi, I did a study with mogo vs Gnu at various
levels. There is NO self play involved, Gnugo-3.7.11 is the only
opponent for progressively higher rated version of Mogo.
Here are the raw results so far:
Rank Name Elo+- games score oppo. draws
1
Helps a little, but I'm still unclear on how a new node is handled.
Do you have lightweight nodes (that only contain info on one positions, with
pointers to children and siblings)? Then when uct finds a node with no
children, what do you do? Mogo and Mark create a new node for each new
David Fotland wrote:
Can you elaborate on what is in a node, and what you mean by expand?
I assume you have simple node, where each node represents a position
and the single move to get there. Then when you find a node with no
children and expand it, you allocate up to 81 new nodes, but
Olivier Teytaud wrote:
Basically, the formula in MoGo combines the success ratio and the
RAVE-success ratio, with more focus on the success ratio when the
number of simulations is large.
You have no bias which favors exploration at all?
--
GCP
___
Unfortunately, I used level 10 in the gnugo only games but in the big
study we use level 8. It's my understanding there is little difference
between these 2 but we can probably assume Mogo might be a little better
than indicated relative to the big scalability study.
Don't you think it would
Christoph Birk wrote:
Unfortunately, I used level 10 in the gnugo only games but in the big
study we use level 8. It's my understanding there is little difference
between these 2 but we can probably assume Mogo might be a little better
than indicated relative to the big scalability study.
David Fotland wrote:
Mogo and Mark create a new node for
each new simulation.
I think MoGo creates child nodes only after the parent has accumulated 5
simulations. You can also change that number with a command-line parameter.
___
computer-go
On Feb 5, 2008 2:22 PM, David Fotland [EMAIL PROTECTED] wrote:
Helps a little, but I'm still unclear on how a new node is handled.
Do you have lightweight nodes (that only contain info on one positions,
with pointers to children and siblings)? Then when uct finds a node with no
children,
Christoph Birk wrote:
Unfortunately, I used level 10 in the gnugo only games but in the big
study we use level 8. It's my understanding there is little difference
between these 2 but we can probably assume Mogo might be a little better
than indicated relative to the big scalability study.
On Tue, 5 Feb 2008, Don Dailey wrote:
I restarted the test, will run 1000 games per level instead of 500 and
I'm running on a different computer and only 1 instance so expect this
to take a couple of weeks.I'll report any results that are not
similar to the previous if it seems noteworthy
荒木伸夫 wrote:
I have considered this, and I think that this may be caused by wrong
training model.
In my master thesis, I mentioned that the relationship between
top 1 accuracy of move prediction and the strength of Monte-Carlo
is not simple (I increased the number of matches to 600, and
Rémi Coulom wrote:
荒木伸夫 wrote:
I have considered this, and I think that this may be caused by wrong
training model. In my master thesis, I mentioned that the
relationship between
top 1 accuracy of move prediction and the strength of Monte-Carlo
is not simple (I increased the number of
David Fotland wrote:
Can you elaborate on what is in a node, and what you mean by expand? I
assume you have simple node, where each node represents a position and
the single move to get there. Then when you find a node with no
children and expand it, you allocate up to 81 new nodes, but
Quoting Gunnar Farnebäck [EMAIL PROTECTED]:
I have never managed to implement RAVE successfully. It made my
program significantly slower but no stronger even at a fixed number of
simulations.
I get a small effect from RAVE, My rationalisation is that if the
program is rich with other
Good point. But he is talking about far more games than would be available
with that method.
Darren Cook wrote:
Unfortunately, I used level 10 in the gnugo only games but in the big
study we use level 8. ...
... it's a major pain running those games and it ties up my
machine.
Hi Don,
I
Unfortunately, I used level 10 in the gnugo only games but in the big
study we use level 8. ...
... it's a major pain running those games and it ties up my
machine.
Hi Don,
I just know your reply is going to make me slap my head and go, of
course, but I've been puzzling over this for 2
Darren Cook wrote:
Unfortunately, I used level 10 in the gnugo only games but in the big
study we use level 8. ...
... it's a major pain running those games and it ties up my
machine.
Hi Don,
I just know your reply is going to make me slap my head and go, of
course,
Lots of good information here. In particular, I notice that my program has the
explore needless captures in progressive widening weakness described below. My
thanks to Magnus (and Remi, of course) for pointing it out. I'll fix that and
then, I guess, I'll have to revisit the issue of reading
My program ggmc has been improved about 300 ELO by RAVE.
-Hideki
Gunnar Farnebäck: [EMAIL PROTECTED]:
David Fotland wrote:
Can you elaborate on what is in a node, and what you mean by expand? I
assume you have simple node, where each node represents a position and
the single move to get
That's very interesting. RAVE, as described in the Mogo paper, incorporated
some priors and gave a progressive widening effect. Have you looked at
progressive widening with and without RAVE? Could you provide some details
about how you made it work?
-Dave Hillis
-Original Message-
24 matches
Mail list logo
