While your goal is laudable, I'm afraid there is no such thing
as a simple tree search with a plug-in evaluator for Go. The
problem is that the move generator has to be very disciplined,
and the evaluator typically requires elaborate and expensive to
maintain data structures. It all tends to be
I am aware such a decoupled program might not exist, but I don't see
why one can't be created. When you say the move generator has to be
very disciplined what do you mean? Do you mean that the evaluator
might be used during move ordering somehow and that generating the
nodes to expand is tightly
Do you mean that the evaluator might be used during move ordering somehow
and that generating the nodes to expand is tightly coupled with the static
evaluator?
That's the general idea.
No search program can afford to use a fan-out factor of 361. The information
about what to cut has to come
Do you mean that the evaluator might be used during move ordering somehow
and that generating the nodes to expand is tightly coupled with the static
evaluator?
That's the general idea.
No search program can afford to use a fan-out factor of 361. The information
about what to cut has to come
This is old and incomplete, but still is a starting point you might
find useful http://www.andromeda.com/people/ddyer/go/global-eval.html
General observations (from a weak player's point of view):
Go is played on a knife edge between life and death. The only evaluator
that matters is is
I really don't like the idea of ranking moves and scoring based on the
distance to the top of a list for a pro move. This is worthless if we
ever want to surpass humans (although this isn't a concern now, it is
in principle) and we have no reason to believe a move isn't strong
just because a pro
George Dahl wrote:
I guess the another question is, what would you need to see a static
evaluator do to be so convinced it was useful that you then built a
bot around it? Would it need to win games all by itself with one ply
lookahead?
Here is one way to look at it: Since a search tends to
Michael Williams wrote:
As for the source of applicable positions, that's a bit harder, IMO. My
first thought was to use random positions since you don't want any bias,
but that will probably result in the evaluation of the position being
very near 0.5 much of the time. But I would still try
Dave Dyer wrote:
If you look at GnuGo or some other available program, I'm pretty sure
you'll find a line of code where the evaluator is called, and you could
replace it, but you'll find it's connected to a pile of spaghetti.
That would have to be some other available program. GNU Go doesn't
On Feb 17, 2009, at 12:55 PM, Dave Dyer dd...@real-me.net wrote:
While your goal is laudable, I'm afraid there is no such thing
as a simple tree search with a plug-in evaluator for Go. The
problem is that the move generator has to be very disciplined,
and the evaluator typically requires
I think it would be much more informative to compare evaluator A and
evaluator B in the following way.
Make a bot that searched to a fixed depth d before then calling a
static evaluator (maybe this depth is 1 or 2 or something small). Try
and determine the strength of a bot using A and a bot
Really? You think that doing 20-50 uniform random playouts and
estimating the win probability, when used as a leaf node evaluator in
tree search, will outperform anything else that uses same amount of
time? I must not understand you. What do you mean by static
evaluator? When I use the term, I
Really? You think that doing 20-50 uniform random playouts and
estimating the win probability, when used as a leaf node evaluator in
tree search, will outperform anything else that uses same amount of
time?
Same amount of clock time for the whole game. E.g. if playing 20 random
playouts to
On Tue, Feb 17, 2009 at 8:35 PM, George Dahl george.d...@gmail.com wrote:
Really? You think that doing 20-50 uniform random playouts and
estimating the win probability, when used as a leaf node evaluator in
tree search, will outperform anything else that uses same amount of
time?
You'll
: [computer-go] Re: static evaluators for tree search
Really? You think that doing 20-50 uniform random playouts and
estimating the win probability, when used as a leaf node evaluator in
tree search, will outperform anything else that uses same amount of
time? I must not understand you. What
Message-
From: computer-go-boun...@computer-go.org [mailto:computer-go-
boun...@computer-go.org] On Behalf Of Gunnar Farnebäck
Sent: Tuesday, February 17, 2009 1:30 PM
To: computer-go
Subject: Re: [computer-go] Re: static evaluators for tree search
Dave Dyer wrote:
If you look at GnuGo
-boun...@computer-go.org [mailto:computer-go-
boun...@computer-go.org] On Behalf Of George Dahl
Sent: Tuesday, February 17, 2009 10:14 AM
To: computer-go
Subject: Re: [computer-go] Re: static evaluators for tree search
I am aware such a decoupled program might not exist, but I don't see
why one
17 matches
Mail list logo
