Re: [gnugo-devel] worm amalgamation question

[Paul Pogonyshev]

Gunnar wrote:
> Paul wrote:
> > could you please explain me why the two white worms are not
> > amalgamated in this position? shouldn't they be amalgamated?
> >
> > |XXX...
> > |OOXXX.
> > |.OOOX.
> > |XX.OX.
> > |.O.O..
> > +------
>
> This is tricky. A golden rule of the experimental connection code (now
> default) is to not amalgamate tactically unstable worms because it
> would lead to difficulties for the move valuation. What's really
> important here is not to amalgamate a tactically critical worm to a
> living dragon.
>
> [...]
>
> Curiously this position has the interesting property that the two O
> strings cannot be solidly connected into a single string without
> allowing a tactical capture. But they can live (in seki) if they
> don't. That is somewhat anomalous to the assumptions made by the
> connection reading code.

unless i am mistaken, white dragon is ko-critical. black * seems to start
a killing ko (even good ko):

|XXX...
|OOXXX.
|.OOOX.
|XX.OX.
|*O.O..
+------

i started this thread because gnu go has tons of problems in a position
starting like this:

|XXX...
|OOXXX.
|.OOOX.
|.X.OX.
|...Ox.         (there may or may not be a stone at `x')
+------

black plays B2 to get seki. at this point gnu go already thinks that the
dragon is dead. this comes from its inability to "block" black stones in
this position:

|XXX...
|OOXXX.
|.OOOX.
|OX.OX.
|.X.Ox.
+------

either C1 or C2 makes seki. otherwise, the position is ko. i have a patch
that finds such moves, but unfortunately it doesn't solve any regression
tests, so i'm doubtful if it should be added to cvs (it's a function called
from owl_find_lunches()).

now consider if white tenuki after black B2. gnu go thinks that black can
kill unconditionally, but my reading shows that black can only get ko. one
of variations is the position i mentioned in the previous mail:

|XXX...
|OOXXX.
|.OOOX.
|XX*OX.
|.O.O..
+------

my patch finds the * move for white, but it requires an extra call to the new
function if white stones are not amalgamated.

note that even if they are amalgamated (or i place that extra call in), gnu
go still can't read the position properly. it requires several owl attack/
defend patterns. so, it's probably too expensive to solve a single position.

Paul