gnugo-devel
[Top][All Lists]
Advanced

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

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


From: Arend Bayer
Subject: Re: [gnugo-devel] GNU Go as an oracle
Date: Wed, 6 Nov 2002 13:36:16 +0100 (CET)

Dan wrote:

> I've posted a patch called oracle_3_12.1 at:
>
> http://www.gnu.org/software/gnugo/patches/oracle_3_12.1
>
> Although I do not propose to add this in its current form to the engine, it
> demonstrates an interesting possibility.
>
> This patch is intended to show how GNU Go could call itself. This
> is similar to the metamachine, except that GNU Go itself serves
> as a gtp controller for a second gnugo process, the "oracle".
(...)
> GNU Go forks and connects to the second gnugo process with a pair of
> pipes. The pattern matcher only tries moves in a restricted area of the
> board, a feature that might be useful for some applications.
>
> Every trymove for the primary gnugo process is matched by
> an actual move by the second process, and each popgo is
> matched by an undo. So all features of the GNU Go engine available
> when stackp == 0 (such as owl attack/defend codes) can be gotten from the
> oracle when stackp > 0.
>
> Of course this is bound to be slow but with fast processors
> it may be feasible to walk a small move tree and do some
> alpha beta search.

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?

Arend







reply via email to

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