Re: [gnugo-devel] Readconnect based dragon amalgamtion

[Gunnar Farneback]

Arend wrote:
> Then we should look for interdependencies of such connections. The natural
> candidate for these are pairs of connections that hold individually but
> not both at a time, e.g. non-transitivity. We only need to test pairs
> of connections that have overlapping active area (where we could maybe use
> an area a little smaller than in persistent caching). If the connections
> A-B and A-C have such a overlap, we test whether B and C are connected. If
> not, then these two connection get marked.

One complication to be aware of is that if B and C are relatively
distant, readconnect may fail to find a connection even if it exists.

> Currently it would probably be most safe to let owl run on the core and
> the tail seperately -- otherwise owl will defend the connection A-C and
> not notice that A-B gets broken. (This should of course be improved,
> but this is unlikely to happen in the near future.)

There's a general problem that the owl code has no provision to
distinguish between living with all stones and living with some of the
stones. This is something we need to address when we get to
redesigning the owl code. Running owl separately for core and tail may
help in some situations but probably not in all. There's also an
increased computational cost to take into account.

> Or maybe pass some indication to the strategical evaluation that the
> cut isn't good. In particular the iken tobi (without too many nearby enemies)
> should be almost connected!

Yes, this must be solved in some way, but exactly how is not so
critical. We have several times in the past (and to a smaller extent
also today) been plagued by a tendency to waste moves needlessly
connecting one space jumps, not seldom making bad shape in the
process.

/Gunnar