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

[Daniel Bump]

> Dan wrote:
> > There's nothing in those two tests which require marginal eye 
> > spaces to be allowed to be occupied G5 would be parsed as
> > (!.) warranting one half eye, while L10 would be parsed as (!) .
> 
> Then you know something about the optics algorithms that I don't know.
> I thought tactically dead stones would always count as part of the
> eyespace. Is that wrong?

We need to distinguish between how things were intended to be
handled back in the days of 2.4 and how we want them to be
handled now. Whether it was working right or not, the original
plan would have had those two eye spaces parsed as
(!.) and (!). I'm not sure it worked correctly in 2.4 but that
was my intention for cases like this.

But we agree that there are examples where this scheme breaks down.
Apparently you and Inge have solutions in mind but I'd like them
to be explained. So:

> > 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.

Dan

(;GM[1]FF[3]
SZ[19]AP[Jago:Version 4.18]
AW[re][rf][rg][rh][sh][ri][rj][rk][sl][bo][bp][cq][br][cr][bs]
AB[qd][rd][qe][se][qf][qg][qh][qi][bj][qj][ck][qk][sk][bl][dl][ql][rl][dm][rm][cn][en][rn][cp][dp][ep][eq][ar][dr][fr][cs][ds]
)