ter-go-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 no
Original 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
omputer-go
> Subject: Re: [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 amoun
On Tue, Feb 17, 2009 at 8:35 PM, George Dahl 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 probably find a variet
> 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 t
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
> 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
On Feb 17, 2009, at 12:55 PM, Dave Dyer 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 elaborate and expens
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 does
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
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 se
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 d
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 tightl
13 matches
Mail list logo
