Re: [gnugo-devel] eyespace reading

[Gunnar Farnebäck]

> Some eye patterns seems not suitable to be applied on the board edge.
> Following condition (3.7.10, recognize_eye() in optics.c, line 1301)
> 
>       if (neighbors[mv] != gv->neighbors
>           || marginal[mv] != gv->marginal
>           || edge[mv] < gv->edge)
> 
> implies that GG hard code always take space on the edge as advantage, but it
> may be the opposite.

No, it implies that edge patterns cannot be matched in the center and
that corner patterns cannot be matched on the edge or in the center.
Corner patterns always precede edge patterns which precede center
patterns in eyes.db (partial ordering) and only the first match is used.
The corner and edge specific patterns may have smaller or larger eye
values as needed.

> For example, Eye Pattern: 420, which yields 1-1-1-2, typically,
> 
> ooooo
> o...o
> ooo.xx
> xxxxxx
> 
> 
> the following position can also matches unexpectedly, and, of course,
> missing the vital point.
> 
> --------------------------
> o...o
> ooo.xx
> xxxxxx
> 
> 
> 
> I am not sure which solution is side-effect free, setup constraints or split
> up those patterns?

Have you tried this on an actual board position? The first case has the
eye graph "...!" but in the second case the topological half/false eye
analysis should detect both a false eyepoint and a halfeye on the edge,
and the eyespace segmentation should find ".h!" which is translated to a
graph matching eye pattern 448 for a 0011 value.

An example where the same graph is found but the value is different on
the edge is

OOOOO
O.X.O
O..XO
OOOOO

and

OOOOO
O.X.O
O..XO
-----

which are matched by eye patterns 6513  and 6504 respectively.

There are things that are tricky with the eyespace analysis though, and
where we don't have very good solutions. These include marginal vertices
of different quality, shortage of external liberties, and cutting points
inside the eyespace.

/Gunnar