Re: [gnugo-devel] PATCH: Marginal eye points with opponent stones in eyes.db

[Gunnar Farneback]

Dan wrote:
> > > OOOOOX         OOOOOXX         OOOOXX
> > > O..XX.         O..XXO.         O..XO.
> > > ------         -------         ------
> > > 
> > > The first is a half eye, the second a full eye, the third
> > > a half eye. In the old scheme each of these would be parsed
> > > as (.!) .
> > > 
> > > If I understand correctly, these are to become (.!)  (..X$) and
> > > (..$). Thus they can be distinguished.
> > 
> > No, the X stones in the two last cases are tactically critical and
> > count as lunches, not eyespaces. This is problematic, but noone has as
> > yet proposed to change this.
> 
> Then how are these 3 cases to be handled? As far as I know the
> last space is (at least up through 3.0.0) supposed to be 
> treated as (.!) . And that's the way it is today. Run
> gnugo -d0x02 on the example at the end of this message.
> You'll see that the eye spaces at T13 and T11 are both
> parsed as (.!). The eye space at T11 is identical to
> the last example.
> 
> If I understand your intention correctly these two eye
> spaces should be handled differently. I suppose that
> means that Inge's patch will have to be complemented
> by revisions to compute_primary_domains(). If this is
> the plan please explain it.

No, there are no current plans to change anything in the analysis of
the eyespaces above. The X stones there are tactically safe or
tactically critical and are not included in the eyespaces.

What Inge's patch is about is the ability to handle positions like
optics:312 through graph matching. That test case is equivalent with
the non-corner eye here

|XXXXXXXXX
|...X....X
|OO.XOOOOX
|.OOOX..OX
+---------

The enclosed X stone is tactically dead, in contrast to the examples
above. Therefore it becomes part of the eyespace. However you had
intended it to be, an eyespace "X.." IS generated by make_domains()
and always has been. Furthermore the X vertex is a topological false
eye and this is equated with a marginal vertex as otherwise, producing
an "occupied margin", which we can denote by the "$" symbol introduced
by Inge. Thus we have the eyespace "$.." which clearly is different
from "X..". It's possible that compute_eyes() could be revised to
generate "!." instead for this eyespace, but I'm doubtful that this
would be easy or even desirable.

Before Inge's patch, the eyespace "$.." could not be matched by any
graph, since there was no symbol that would match an occupied margin.
Instead linear_eyes() was modified to give a correct answer here, in
order to solve test case 312. Similarly the eyespace "$X." was
hardcoded in linear_eyes().

For various reasons, essentially boiling down to reducing code
complexity, it would be desirable to get rid of linear_eyes(). Since
the two eyespaces "$.." and "$X." are fairly common, these have been
showstoppers. Inge's patch allows us to add patterns like

Pattern 307

$*.

:1,0

Pattern 308

$.X

:1,1

Pattern 309

$X.

:0,0

and then we can throw out linear_eyes().

/Gunnar