gnugo-devel
[Top][All Lists]
Advanced

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

Re: [gnugo-devel] GNU Go 3.3/3.5


From: Arend Bayer
Subject: Re: [gnugo-devel] GNU Go 3.3/3.5
Date: Sat, 27 Apr 2002 20:25:18 +0200 (CEST)

I wrote:

> > 2. Rewrite strategical evaluation to a strict before move/after move
> >    comparison. This has to use: moyo size, eye shape, esacpe values, ...

> > 6. Replace dragon amalgamation by s.th. based on readconnect (and with it
> >    of course the connect/cutting move generator).
> >
> > 7. I'd like to write a new module to analyze fights involving multiple
> >    dragons.

Dan wrote:
> These are all good ideas. (2), (6) and (7) seem projects for later.
> Actually for (2) I think it is important to eventually do this
> but there seem to be more urgent things first, (6) may be on
> Gunnar's connection agenda and (7) is harder than (2).

(7) is definitely hard, and I don't think it makes sense to do that before
both (2) and (6) are working.

> Our biggest problems right now include failure to recognize
> the weakness of groups, and a tendency to develop groups, then
> abandon them. I don't think we currently have a cogent plan
> for fixing these problems, but if we could we'd have an
> immediately stronger engine.

I'd hope that this can be solved one at a time with doing (2). What I
imagine is:
 - Spend a lot of tuning effort on computing the safety value of a group.
   The result should not be expressed in a finite number of steps (WEAK,
   ALIVE, STRONGLY_ALIVE...) but directly as a floating point number. This
   should make it possible to tune the valuation better than currently;
   e.g. IMHO one of the important reasons why GNU Go fails to recognize
   weak groups is that a group with high escape value is at least ALIVE
   regardless of how small the moyo is. This means e.g. in the fuseki that
   the engine does not see the need to extend a stone. Such things should
   be more easily tunable with a continuos set of safety status.
 - This computation has to make use not only of the pre-owl but also of
   the post-owl influence computation. Currently, it has no effect on the
   safety whether a group has a dead hostile dragon as neighbour.
 - Once this is done, it should not be much work to do the same with the
   post-move influence computation, and then we can just compare the two
   safety values we get. This should immediately increase the valuation
   of moves that rescue a critical dragon, as the effect on its neighbours
   are taken into account.

Of course there are also a lot of cases where GNU Go abandons a group
because it wrongly assumes it is dead (or because the owl result is
uncertain), and they need attention, too.

Arend





reply via email to

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