[computer-go] Example for Morphys law in Evaluation
Magnus Persson
magnus.persson at phmp.se
Wed Sep 20 15:41:32 PDT 2006
Quoting Chrilly <c.donninger at wavenet.at>:
> Enclosed is a simple example were these 2 rules produce in a very
> simple positionl nonsense. According to rule 1 the dead black group
> is upgraded to weak, because the white group on q2 is more dead
> (black to move is assumed).
> In pass 2 the weak black group finds again a weaker neighbour group,
> q2 and its therefore updated to okay.
One thing I think is missing in your rules, is that a dead/weak
adjacent groups
must be evaluated with respect to how many eyes they provide if they are
captured.
Capturing Q2 has now eye value whatsoever. The only value of it is that a
liberty can be gained.
You need to carefully evaluate the number of effective liberties of all groups
so you know which group is weak relative to what groups.
You cannot in general do this correct in two passes, because longer chains of
dependencies makes group evaluation arbitrarily complex. I have probably
written about 3 different attempts at doing this kind of analysis and ended up
with some kind of recursive analysis.
My old program Viking4 (not to be confused with Viking5) made some pretty good
static analysis of isolated groups, but when it came to modifiying the eval of
the groups using interactions between groups it was a complete mess. And in
real games of go positions are most difficult to evaluate when the fights
begin. When the program finally can apply its heuristics properly it is
already
too late... all stones are dead.
Even more tricky is too evaluate groups that are not touching each
other but is
nethertheless tacticallly dependent on each other.
It is also not clear to me what exactly you are trying to achieve.
My static evaluation of groups was supposed to
a) Group stones together that were guaranteed to be connected against any
tactical combination.
b) Evaluate the number of eyes (With half eyes as the minimal unit) that is
guaranteed against any tactical combination (and also not violate a).
In principle this is possible to do with specially handmade patterns that are
matched to a "possible" group such that if they do not overlap the chains are
glued together by each pattern. If patterns overlap, there is a possiblilty
that an attack on the overlapping part of the board may be an effective double
attack and break the connectivity/eye status of at least one pattern.
The advantage of this tight definition of what a group is, is that a group is
evaluated as alive there is not need for tactical search at all for
that group.
Viking4 can in some cases play very accurate with 1 ply search only as
it could
read 20 ply deep with respect to the status of single group.
The disadvantage is that in realistic positions a lot of stones are loosely
connected and then one has to apply some heuristics for evaluation for those
loose groups.
I had two more representations/concepts in my evaluation.
"Clouds": If A is connected to B and B to C then ABC is a Cloud. ABC
may also be
a group but only if the AB And BC connections are tactically independent.
"Meta Clouds": If the Influence of A and B overlaps to some degree they form a
Meta Cloud.
So basically I had three different ways of looking at what a group is and then
evaluating the strength of these types while also including interaction with
neighbouring groups is very very hard.
I tried hard to define a very exact method of doing static evaluation, and it
there is a lot of real world go game position where it works as intended. But
in about every game the program plays the full board search (1 ply) will
quickly gravitate towards positions where evaluations are incorrect. I found
that it was easy to fix mistakes by adding patterns that improved groups. But
there seemed to be any infinite amount of positions which each required its
unique fix.
It is late here in Europe and this post is not very coherent. So here is the
point: "Static evaluation of groups in go is very very difficult. Monte Carlo
evaluation was sent from heaven".
-Magnus
More information about the computer-go
mailing list