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

[Daniel Bump]

Gunnar wrote:

> The two most interesting cases are covered by test cases
> optics:312,325. Currently those are handled by linear_eye_space().
> After Inge's patch all the 300+ lines of code in linear_eye_space()
> can be replaced by eye patterns.

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 (!) .

There ARE situations where the old scheme isn't sufficient,
such as:

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 (.!) .

As far as I know the only issue that can't be dealt with in
the old scheme have to do with the fact that if three stones
are captured on the margin of an eye space then an eye results.

If I understand correctly, these are to become (.!)  (..X$) and
(..$). Thus they can be distinguished.

But this isn't supported by any documentation or even by what's
actually in eyes.db. (There are only two patterns using the
$ code.)

I put up a patch optics_1_17.1 which should prevent
linear_eye_space() from returning a vital point which is
already occupied. There are definitely cases (before and
after the patch) where linear_eye_space() doesn't do the
right thing. Hopefully there are fewer after the patch
than there were before.

Dan