Re: [gnugo-devel] owl problem

[Gunnar Farneback]

Arend wrote:
> I would have liked to award a serious penalty to dragons whose owl
> status is uncertain. However, look at:
> http://www.public32.com/regress/?trevorc:380
> (There were other examples, too.)
> 
> The huge white dragon in the center actually has an uncertain owl result
> both for attack and defense. I can of course work around this in the
> strategical evaluation. But spending 2000 owl reading nodes on such an
> obviously alive dragon is clearly a waste of time.
> It looks like there is a problem here, and that we could fix a huge
> number of owl nodes by fixing that (and then we could also enlarge the
> owl node limit for those case where we really need it).

Yes, this is an old problem, which might be slightly tricky to
explain. What follows is somewhat simplified. To begin with, the owl
code would stop reading if it realized that the dragon had eyespace
definitely worth two or more eyes. This is apparently the case here
since we have a rather huge eyespace. Without going into the workings
of the optics code, compute_eyes() comes to the conclusion that this
eyespace is worth two eyes. However, the local game model used by the
optics code doesn't take certain complications into account, such as
atari inside the eyespace. To offset for this the owl code has the
"vital attack patterns". The number of matches for those is more or
less subtracted from the lower estimate of the number of eyes made by
the optics code.

So what happens here is that compute_eyes() sees a big eyespace and
reports min two eyes. Then a couple of vital attack patterns are
matched (e.g. atari at H1 and peep at F5) causing the owl code not to
trust what compute_eyes() reports and instead it tries whatever moves
the owl patterns come up with. (Which in this case are not terribly
effective.)

There are a couple of ways to attack this problem, including:
1. Allow compute_eyes() to return larger number of eyes than two for
   huge eyespaces.
2. Generate moves to eliminate the vital attack pattern matches.
3. Move the responsibility for taking atari inside the eyespace and
   similar complications into account to compute_eyes().

The first solution is simplest but not necessarily very effective. The
last solution I believe is the best one in the long run but not very
easy to implement.

/Gunnar