Hello,
Is there any known (by theory or tests) function of how much a increase
in the strength of the simulation policy increases the strength of the
MC/UCT Program as a whole?
I think that is a very interesting question.
In our work on MoGo we found that there could be a decrease of the
In our work on MoGo we found that there could be a decrease of the
strength of the MC/UCT program while using a stronger simulation
policy. It is why in MoGo it is more the sequence idea, than the
strength idea. Our best simulation policy is quite weak compared to
others we tested.
Could you
Could you elaborate on the sequence idea? Or point me to somewhere
where you have already done so?
Sure. We already describe it in our research report that you can find there:
http://hal.inria.fr/inria-00117266
or there if you prefers the web interface in english but with a longer URL :-)
Hello,
David Doshay wrote:
On 3, Feb 2007, at 2:51 AM, Sylvain Gelly wrote:
the speed of the best simulation policy in MoGo is 0.6 * the speed
of the uniform random one.
I think that this is very good. You give up less than a factor of 2
from uniform random and you probably get better than
Unfortunately, it's just not that simple, because it depends far more
on _how_ the playout is improved, rather than, say, the ELO numbers
that measure that improvement. For example, programs exist that are
good (in part) because they entirely disregard some lines of play.
They may be correct to
Hello Don,
I have the same situation with an older program that has a more
sophisticated data strucutre. If I was building a smarter
program I would rather use the older but slower code but I
cannot optimize it any further for simple randomly uniform
play-outs. If I compared the old code
From: Sylvain Gelly [EMAIL PROTECTED]
I truly believe that we can make big steps in this direction and getting
much better (real not simulation) players that way.
Hi all,
Thanks for answering Sylvain.
I find MoGo already very impressive, so it surprised me that
you think that more big steps
Hi Edward and hi all,
I truly believe that we can make big steps in this direction and getting
much better (real not simulation) players that way.
I find MoGo already very impressive, so it surprised me that
you think that more big steps are possible.
I do really think that it is only a
I seriously doubt a highly optimized MoGo would be able to stay
this close to uniform random in speed.
It's already been pointed out that a lot of MoGo is infrastructure
to support interesting experiments.I'm guessing here, but my
guess is that the uniform random implementation is suffering
Your english is fine, it's my grammer that could use some help.
I made it more complicated than it needed to be.
You mentioned that you have a slow but flexible data structure
that supports lots of experimentation but makes the program
slower.
But it occured to me that a simple version that
David Doshay wrote:
I am a physics guy, and my thesis project was a large MC simulation.
The clusters that run SlugGo are usually busy doing MC simulations when
not playing Go.
In general MC needs to sample according to the proper distribution for
the problem. For some problems in quantum
are different beasts. If SlugGo's mixture of experts work expands to
include MC/UCT, you might want to consider adding one of each.
- Dave Hillis
-Original Message-
From: [EMAIL PROTECTED]
To: computer-go@computer-go.org
Sent: Fri, 2 Feb 2007 12:30 AM
Subject: Re: [computer-go] Monte-Carlo Go
On 2, Feb 2007, at 9:08 AM, [EMAIL PROTECTED] wrote:
I agree with what you say here and I'll try to make my point
better. First, my limited experience working with Monte-Carlo
simulations involved photons traveling through scattering media.
The sequences of moves described in the Mogo
David Doshay wrote:
But I am not sure what the value is in what you are
calling light playouts.
As per the above, it seems to me that light playout
is simply ignoring any proper distribution, and thus
is just a much more inefficient way to sample.
Well maybe Sylvain is willing to answer
-Original Message-
From: [EMAIL PROTECTED]
...
The earliest MC engines were extremely simple and easily described. It
seems inevitable that someone new to the field will seize on this
description, and then combine it with the success of current Monte-Carlo
engines, leading to
[EMAIL PROTECTED] wrote:
-Original Message- From: [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] ...
The earliest MC engines were extremely simple and easily
described.
It seems inevitable that someone new to the field will seize on
this description, and then combine it with the success
Is MC Go a misnomer for programs in this genre not using simple random
playouts and combining with other techniques like pattern matching?
Technically, does the general Monte-Carlo method require random or
pseudo-random sampling?
If so, should we dub a new name for these non-random deep
17 matches
Mail list logo
