Re: [gnugo-devel] eye patterns

[Gunnar Farneback]

Paul wrote:
> - different kinds of marginal vertices supported by graph matcher
> 
> see comments in eyes.db part of the patch for details.

+# The patterns that look the same but differ in types of marginal
+# vertices (see below) are sorted in the order "any", "neutral",
+# "biased" from the first marginal vertex to the last.
+#
+# #######
+#
+# The semicolon lines that appear after some patterns specify the types
+# of marginal vertices which can be matched against pattern's vertices.
+# Allowed types are "any", "neutral" and "biased". Consider this artificial
+# position:
+#
+#       XXX            Both white dragons have one eye each. However, the
+#   OOOOOX.XOOOOO      eye to the right is safe as it stands, while the
+#   OXXX!XX.!XXXO      one on the left needs defense immediatly. Both
+#   OOOOOX.XOOOOO      vertices marked with '!' are marginal, but they
+#       XXX            are clearly different. The left one is called
+#                      "neutral" since it has alive neighbors of both
+# colors. The right one is "biased" for it favors one of the players.
+#
+# "any" is of course a wildcard, it allows any marginal vertex to match
+# against a given position in a pattern. It is the default type and when
+# a pattern doesn't have a semicolon line, all it marginal vertices have
+# "any" attribute set.

There are certainly marginal vertices of very varying quality. The
local game model used as rationale for the optics code implicitly
assumes that marginal vertices connect to a sufficiently safe string,
which is the best possible situation for the attacker. In practice
there are a lot of different cases, including false eyes, which are
handled as margins.

For an example, consider these positions:

|......      |.X....
|..XXXX      |..XXXX
|.XO.X.      |.XO.X.
|.XO.X.      |.XO.X.
|XOO.X.  vs  |XOO.X.
|.OOOX.      |.OOOX.
|...OX.      |...OX.
|.OOOX.      |.OOOX.
|OO..X.      |OO..X.
|XXXXX.      |XXXXX.

To make things even more complex, topological half eyes are modeled by
adding a margin to the eyespace graph.

Regarding the patch I'm doubtful about adding a partial classification
of the margins. Either we should try to make a mostly complete
classification or to solve the problem by other means. Personally I
don't think the added complexity of the eye database required to
support margins of various kinds can pay off but that we should try to
add a layer between the owl code and the optics graph matching which
does limited reading to check for e.g. difficulties with margins.

In any case I'd like to see examples of the various kinds of margins
that exist. It should help much in the further development of the eye
analysis code to have such available.

For now we could maybe use the patch, but the question of added
complexity in the eye database remains. Does anybody else have an
opinion whether it pays off?

> -Pattern 5225
> +Pattern 5229
>  
>   X
>  XX.!
>  
> -:0112
> +:1112

I notice there are some revisions which are independent of the margin
issues. Is there any chance to isolate those for separate review?

/Gunnar