gnugo-devel
[Top][All Lists]
Advanced

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

[gnugo-devel] moyo reduction


From: Arend Bayer
Subject: [gnugo-devel] moyo reduction
Date: Wed, 5 Dec 2001 16:30:00 +0100 (CET)

I have been deliberating a while on GNU Go's moyo weakness, and I think
I have some more or less concrete suggestions how to improve it. What
I am writing is rather focussed on the reduction of enemy moyos. I guess
this is more urgent; I think the successes of some other programs via
building moyos is rather due to their opponents letting them finish it.
However, parts of what I would like to do is very delicate in that it
could break a lot of tuning, so I would like to invite some discussion
on the matters.
My general assumption is that moyo reduction moves should be treated
in the same way as other moves as far as this is possible. In particular,
GNU Go should be able to evaluate their territorial effect reasonably
with its usual valuation procedure. If this is successful, we could on
the way also drop the enforced minimum value of such patterns as LE14,
LE6, LE11.


1. The current territorial valuation with its 3 steps (area = 0.13,
moyo = 0.35, territory = 1.0) is too coarse and should be replaced
by a continuos function interpolating between the existing threshholds.
I can give two reasons for this: A typical huge opponent's moyo usually
is worth 0.35 pts everywhere, although it should be worth considerably
more. After a jump breaking into this moyo, only intersections very close
to the played stone fall below the moyo threshhold; most of the opponents
moyo is still worth 0.35 pts although its value should have decreased.
In my opinion this is the most important reason why such jumps are
undervalued. (I also believe that other odd results of the territorial
valuation will be smoothened by this change.) The other (minor) reason
is that the 3rd step below probably needs a somewhat stricter definition
of moyo than the current one.
To tune this part (together with some possible further fine tuning of
the influence function), one could e.g. use positions from professional
games, assume that the pros have played perfectly, and see how
accurate the influence-based score estimation predicts a jigo.

2. Moyo reduction moves typically have a big followup moves that cannot
be easily valued by patterns; the same is true for every move that sets out
into a wide open space. I suggest a simple workaround for this: In
compute_move_influence, the move played could get a strenght of s.th.
around 150 instead of 100. Again this is a delicate tuning matter.

3. After these two changes GNU Go should hopefully have learned to
jump into an opp's moyo where such a move is suggested already today
by pattern matchning. Now one could try to write a module that suggests
reducing moves not directly (=locally) related to friendly stones. This
should roughly go as follows: We need to identify the open borders of
opp's moyo. For this one could e.g. just go around its border, and try
to identify bigger gaps between surrounding stones. Another idea would
be to trace the way our own influence intrudes into the moyo (such
influence should exist, otherwise the moyo would be territory already).
At these open sides one could then try to find a conditional local maximum
of destroyed opp's territory, the condition being (e.g.) that the 
escape value (or rather a refined version of it) does not drop below
a certain value.
Of course, this does not find moves that break into opp's moyo by
identifying weaknesses in the opp's connections around it, and then
using techniques as cross-cut, sacrifices etc. Go4++ seems to do s.th.
like this, but I don't think GNU Go could learn a careful application of
such moves without some bigger changes in the engine.

So, once again I add more to the to-do-list than to the actual code :-),
but I feel these ideas could benefit from some further deliberation
while I am still working on the issues I raised with the strategic
effect. I would be happy about any comment!

Arend





reply via email to

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