[computer-go] Example for Morphys law in Evaluation

Chrilly c.donninger at wavenet.at
Thu Sep 21 00:14:52 PDT 2006


>
> Capturing Q2 has now eye value whatsoever. The only value of it is that a
> liberty can be gained.
>
This solves the problem in the concrete position. But it does not solve the 
general case where there are yet no strictly enclosed regions and eyes. Just 
2 or more loosly formed groups which are weak and fight against each other.

>
> 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.
>
But even with a recursive approach one has do decide at each level which 
groups must be considered dead or weak. Otherwise there is no progress in 
the recursions. If this decision is wrong, the following is also wrong.

> 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.
>
And a search finds the fact that it is dead somewhat earlier. This can make 
things worse, because it starts bad delaying moves. There is a famous 
example in computer chess. At the WC in 1971 (+/-) Kaissa gave seemingly 
without reason a knight away. The programmer thaught that its a bug. In fact 
Kaissa had seen a mate and sacrificing the knight was the only way to avoid 
it. Probably the opponent programm would not have found the mate.

> Even more tricky is too evaluate groups that are not touching each other 
> but is
> nethertheless tacticallly dependent on each other.
>
I consider opponent groups which are directly adjacent or have at least 1 
common liberty with the dead/weak group. There are of course more indirect 
influences, but it handles the basic question, is there any weaker group 
around reasonable (ot Suzies playing level). This is identification of 
potential opponent groups is at the moment not the problem.

> It is also not clear to me what exactly you are trying to achieve.
>
To determine the status of a group. In the example at hand. Are the four 
courner squares under blacks or whites control? In step one the 
strength-safty of the group is calculated without considering the strength 
of neighbour groups. In step one the programm knows, that it has 4 
Eyepoints, but this is not enough for living, because its a square-4. But 
this does not automatically mean, that the group is dead. If there would be 
a weaker neighbour group which can be attacked, the black group can still be 
alive.
This is also important in the general case, were there are still not eyes 
formed and a few loose groups are fighting each other. Its especially 
important if the groups are weak but not definite dead or strong (I avoid 
the term alive, because this analysis is not directly L&D related).

> 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).
>
Step a) is in Suzie the same. Suzie knows some basic patterns which are at 
least hard to break. E.g. 2 common libs, protected common libs, 
Ikken-Tobi-From-Stretch, Monkey-Jump.
In Step b) I see the problem, that Live and Death starts much earlier. When 
there are still no (half-)eyes there. E.g. playing a single stone into the 
opponents territory. Has this stone any chance to survive?
>
> 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.
>
Yes exactly, see above.
>
> 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".
>
One should always inspect the gifts carefull. Even if the gift  comes from 
heaven. It can be a Trojan horse.

Chrilly



More information about the computer-go mailing list