On Jul 6, 2009, at 10:09 PM, Peter Drake wrote:
I suppose I could also include first child / next sibling pointers.
I wouldn't actually use them when performing playouts, but they
would greatly speed up the mark phase of marking and sweeping.
Hmm. That would work for a tree, but this is a
Although the number of games explored is very limited relative to the total
number of possible games, those games are in some sense representative of
what happens if you start with a particular move. That's why they can help
to create a ranking that tells you something about which moves are
Quoting Oliver Lewis ojfle...@gmail.com:
Others on this list have reported in the past that the randomness is
actually very important. Playouts that are very heavy, no matter how
clever they are, actually reduce the performance because they narrow the
number of games too much.
I would like
On Tue, Jul 07, 2009 at 09:16:25AM +0200, Oliver Lewis wrote:
You should also read up on the all moves as first (AMAF) technique. This
is even more surprising because it attributes the outcome of a random game
to every move of that colour during the random game, as if that was the move
that
Fred,
others have already indicated that you are missing the tree part of
Monte Carlo Tree Search, but there is something else to add.
If you run uniform random playouts on an empty 9x9 board, let's say a
million of them for each point, you will see a probability distribution
emerging that
The problem I think is to find a good tradeoff between heavyness and
speed. In my test with Valkyria vs Fuego, Valkyria is superior when the
number of playouts are the same. But Fuego can play 5 times more
playouts per second on the hardware that results in Fuego being slightly
stronger than
What is the motivation in this? I cannot conceive of any good reason for
running an experiment this way, so I would be interested in opinions. It
seems to me that making algorithms heavier and then demonstrating that
they are stronger with the same number of playouts misses the point -
why
Darren Cook wrote:
seems to me that making algorithms heavier and then demonstrating that
they are stronger with the same number of playouts misses the point -
why would one not run an experiment under the same time conditions instead?
* The heavier algorithm might be unoptimized;
That
* The scaling behaviour might be different. E.g. if fuego and Valkyria
are both run with 10 times more playouts the win rate might change
I am not sure I follow this argument. How do you intend to prove that,
unless you run the algorithms with 10 times more playouts?
I think showing
Quoting Darren Cook dar...@dcook.org:
* The scaling behavior might be different. E.g. if Fuego and Valkyria
are both run with 10 times more playouts the win rate might change. Just
to dismiss an algorithm that loses at time limits that happen to suit
rapid testing on today's hardware could mean
My conclusion was that the winning percentage is more than just an
estimate of how likely the player is to win. It is in fact a crude
estimator of the final score.
Going back to your original comment, when choosing between move A that
leads to a 0.5pt win, and move B that leads to a 100pt win,
On Tue, Jul 7, 2009 at 3:49 AM, Magnus Persson magnus.pers...@phmp.sewrote:
Quoting Oliver Lewis ojfle...@gmail.com:
Others on this list have reported in the past that the randomness is
actually very important. Playouts that are very heavy, no matter how
clever they are, actually reduce
Experiments with equal playouts are much easier to control to get accurate
results.
David
What is the motivation in this? I cannot conceive of any good reason for
running an experiment this way, so I would be interested in opinions. It
seems to me that making algorithms heavier and then
Many Faces has won almost 100 games in a row to get a high rating, but
without an anchor, that rating is probably not accurate. Is anyone willing
to put up an anchor or a stronger program that has lots of games and a
stable rating?
David
___
On Tue, Jul 7, 2009 at 6:31 AM, Christian Nentwich
christ...@modeltwozero.com wrote:
The problem I think is to find a good tradeoff between heavyness and
speed. In my test with Valkyria vs Fuego, Valkyria is superior when the
number of playouts are the same. But Fuego can play 5 times more
Don,
I see where this argument comes from, but you are not taking it to its
conclusion. Unless you can, in the end, show that your algorithm can
outperform another one with the same time limit, you have not proved
that it is an advance. That is why tournaments are played with time
limits,
Magnus,
along the lines of the argument I am trying to make: did you try your
experiments with time limits from 30 seconds per game to five minutes
per game (say), rather than playouts? Using gogui-twogtp this is
relatively easy to achieve.
I am obviously not associated with Fuego, but I
On Tue, 2009-07-07 at 17:09 +0100, Christian Nentwich wrote:
[..] Unless you can, in the end, show that your algorithm can
outperform another one with the same time limit, you have not proved
that it is an advance. That is why tournaments are played with time
limits, not limits on the
megasnippage of Don's post:
Adding an additional order of magnitude more time to the search [ in Rybka]
is not
going to change the basic misconception if the evaluation just doesn't
understand the position. [ Don suggests that this applies even more so to Go ]
Amen! We've covered variants of
If your program is limited by memory size, then it makes sense to
limit experiments by trial count.
Running on your development computer, you might be limited by
clock time. Running on competition hardware, you might not be.
___
computer-go mailing
Brian Sheppard wrote:
Running on your development computer, you might be limited by
clock time. Running on competition hardware, you might not be.
Only if the algorithm doesn't scale.
Which makes it uninteresting to begin with.
--
GCP
___
On Tue, Jul 7, 2009 at 12:09 PM, Christian Nentwich
christ...@modeltwozero.com wrote:
Don,
I see where this argument comes from, but you are not taking it to its
conclusion. Unless you can, in the end, show that your algorithm can
outperform another one with the same time limit, you have
Running on your development computer, you might be limited by
clock time. Running on competition hardware, you might not be.
Only if the algorithm doesn't scale.
Perhaps there is a misunderstanding? A scalable algorithm is
limited by the hardware it runs on. The limit may differ when you
I have not used time exactly to match up Valkyria and Fuego. But also
with fixed numbers of simulations one can match them up closely in
processor time. And then I do that Valkyria wins something like 41-45%
of the time.
I never intentionally designed Valkyria to work well small number of
Digesting Don's remarks, it seems that a reasonable method would start with
equal numbers of simulations. It could then proceed to try various
optimizations, and compare algorithms which use equal time.
It makes perfect sense for the ultimate goal to be better performance using
the same time
something i've played with a little bit:
only look at algorithms with the following
property:
* they every so often update an in-memory score for each board position.
you can then run a timing loop around this and just make the
highest-scoring valid move the play. you can use a signal handler
MC bots play handicap games poorly.
...
So my suggestion would be to pretend that there is a komi that almost
compensates the handicap.
The same ideas has been suggested before [1]. The counter comments were
mostly that hard to get right or tried that briefly and it didn't
work well.
Darren
27 matches
Mail list logo
