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

[Evan Berggren Daniel]

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.

Thanks

Evan Daniel