[gnugo-devel] Owl and connections

[Arend Bayer]

Gunnar wrote:

> Nando wrote:
>
> > The first issue I've been facing is the fact that the escape map is static
> > and doesn't get updated during owl reading. At stackp >= 10, things might
> > have changed a bit around the attacked dragon and there's a good number of
> > patterns which rely on owl_escape_value()... I've made small attempts at
> > solving this, but nothing useful so far. Anyway, it doesn't seem to be
> > very urgent, although I think it should be addressed soon or later.
>
> The reason why it's not just recomputed is of course speed. It's
> possible that one could do some kind of inexpensive updating but I
> don't think anyone has explored that.

Regarding the escape values, I see two more urgent issues: We should avoid
escaping towards other parts of the same dragon, and avoid escaping towards
stones that are almost dead themselves. I hope to spend some time on this,
but I think some cleanups in the influence code should go first.

> > The other issue is the important assumption that a dragon is an
> > unsplitable unit. Although I can understand the reasons which pushed to
> > that choice at first, it seems simply unacceptable to me. A couple

> This is well-known and one of the major weaknesses of the owl code.
> When the owl code was first written it was completely unfeasible to do
> it otherwise. Today we're in a much better position to revise this
> thanks to the readconnect code but I don't think anyone has looked
> seriously into that either.

It sounds for too expensive to test all relevant connections at each move.
However maybe one could misuse compute_connection_distances() in the
following way:
At each move, we compute the distances for a few of the core worms of the
dragon (or maybe all of them, but that might already be too expensive). We
remember the distances. Whenever a distance between two worms jumps up,
we suspect there could now be a cut, and test for it.

Opinions? Ideas? It would certainly require a lot of work to make that work
well.

Arend