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

[Arend Bayer]

Dan wrote:

> Yes, exactly.
>
> GNU Go can be made stronger than current engines without radical
> changes. But to make a really strong engine we're going to have to
> do something different.
>
> I think the key is semilocal search, generating moves in a
> restricted area of the board, generating, saving and maintaining
> from move to move a small move tree.  When the opponent moves, the
> tree is pruned at the base, then deepened if necessary.

This is a minor point, but I think it is not necessary to introduce a
handling of move trees. Just transposition tables seem completely
sufficient to me. If a table is still deep enough in the next move,
keep it. If not, use it for move ordering (i.e. try the move that came
best in the previous search first, in the same way as when doing
iterative deepening), start a new table and throw away the old one
afterwards.

> The biggest obstacle is speed. The schemes I have in mind would be
> too slow currently and also require multiple GNU Go processes
> communicating by unix pipes so there will be portability
> problems. So when this stuff is ready to go into the engine it will
> have to be a configure option turned off by default.

But then the different processes do not share caches/persistent caches
etc? (Or else if you want one process with different threads, then
we will probably have to rewrite a lot of stuff to clashes.)

> > 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.
>
> This can be accomplished quickly within the context of metamachine search.
> Currently the evaluation of positions is not good enough, for example
> interface/gtp_examples/metamachine.c is weaker than gnugo.

I think the main problems are the same. Your metamachine basically knows
nothing about strategic effects, atari-atari moves etc. Also it does
not use the fine tuned influence code as far as I understand.

> What you have in mind is different. You want a single GNU Go
> process to use a revised move valuation scheme. This is not
> incompatible with what I'm doing and is probably a step in the
> right direction.

Yep.

Arend