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 o
On Tue, Jul 7, 2009 at 3:49 AM, Magnus Persson wrote:
> Quoting Oliver Lewis :
>
> 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 narro
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
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
Quoting Oliver Lewis :
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 to disagree with t
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 better
George Dahl wrote:
I think he is missing the tree search part. Just doing a one-ply
lookahead and then doing playouts will not make a strong bot. I would
like to defer an explanation of UCT (or something else) to someone who
is more of an expert.
UTC would add little if MC itself were not a l
That's the beauty of MC! It really is a beautiful system. Initially, they were totally random playouts. But the more powerful MC Go engines do not do
completely random playouts; they do "heavy" playouts. But if you were to look at a heavy playout, it would still look like a very weak Go player
I think he is missing the tree search part. Just doing a one-ply
lookahead and then doing playouts will not make a strong bot. I would
like to defer an explanation of UCT (or something else) to someone who
is more of an expert.
- George
On Mon, Jul 6, 2009 at 8:25 PM, Raymond Wold wrote:
> Fred
Fred Hapgood wrote:
I have a really basic question about how MC works in the context of Go.
Suppose the problem is to make the first move in a game, and suppose we
have accepted as a constraint that we will abstain from just copying
some joseki out of a book -- we are going to use MC to figure o
I have a really basic question about how MC works in the context of Go.
Suppose the problem is to make the first move in a game, and suppose we
have accepted as a constraint that we will abstain from just copying
some joseki out of a book -- we are going to use MC to figure out the
first move de n
11 matches
Mail list logo
