[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gnugo-devel] GNU Go as an oracle

From: Evan Berggren Daniel
Subject: Re: [gnugo-devel] GNU Go as an oracle
Date: Wed, 6 Nov 2002 09:02:21 -0500 (EST)

On Wed, 6 Nov 2002, Arend Bayer wrote:

> GNU Go can certainly be improved a lot by continued tuning, bug-fixing,
> improving the integration of the readconnect code and -- maybe most
> important -- fundamental improvements in the owl code. But I agree with
> Dan (assume this is your motivation for oracle), that in the long run we
> will have to do some local or global alpha-beta search.
> At the moment we are probably not yet ready for starting this. However,
> I think we should keep it in mind as a goal and at least not make it
> harder to get there.
> One important step would be to shift the move valuation step by step to
> a strict before move/after move comparison. (I.e. we should evaluate
> positions, not moves).  This might be a little harder to tune, but I think
> in the end it is more clear and possibly cleaner code.
> Examples of such changes are Inge's recent strategic evaluation patch,
> my changes to the blunder code (where this change made it btw much
> easier to get a better evaluation). Further examples could be
> atari-atari and attack either moves.
> Comments?

I agree completely.  One very important place to do things like this is
for josekis.  Ideally we would pick josekis using an alpha beta search of
all known josekis, and perhaps eventually also include on-the-spot
variations if needed.

Another interesting idea woud be to look at the proposed move, the
opponent's obvious answer, and our answer to that, and then try valuing
that move instead (and perhaps also try the opponent's predicted move).

Also, this sort of thing is fundamentally how we deal with multiple
threats -- moves that threaten to escape or make eyespace, for example.


Evan Daniel

reply via email to

[Prev in Thread] Current Thread [Next in Thread]