Re: [gnugo-devel] Pattern A1120

[Gunnar Farneback]

Nando wrote:
> Still, this study showed me a couple issues, which will be difficult to
> ignore. Maybe what follows is long time known here, sorry about it if it's
> the case.

I'm not sure whether it has been discussed much but it's certainly
known by the people who have done some serious owl tuning.

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

> 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
> examples: I've seen the engine play 3 successive one space jumps and
> declare WIN by escape while all the original stones were getting cut (and
> killed of course). Another time I saw the engine declare WIN by "2 or more
> secure eyes", but it hadn't noticed the 2 eyes just got disconnected !

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. 

> I have a couple ideas about the 2nd issue, but I wish to get some opinons
> about it before I start working. So, what do you think ?

Let's hear your ideas. Speed is probably the critical issue.

/Gunnar