[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [gnugo-devel] owl:11
From: |
Evan Berggren Daniel |
Subject: |
Re: [gnugo-devel] owl:11 |
Date: |
Thu, 10 Apr 2003 20:26:03 -0400 (EDT) |
On Thu, 10 Apr 2003 address@hidden wrote:
>
> > In general I'd agree that seki should be handled by owl. However, it
> > would seem to me that this could result in cases where the tactics code
> > thinks the string is dead, but cannot find an attack point. That seems
> > like a mild problem to me, and simple seki handling (treat it as tactical
> > life) seems like a reasonable solution. Is there a reason this is a bad
> > approach, beyond it really being the responsibility of the owl code and
> > possible performance issues? (Which is not to say I think those are bad
> > reasons, I'm just curious.)
>
> Seki, for example in this position, is a property of two dragons,
> not their constituent strings.
>
> I think if you think about it this is obvious. In order to
> recognize that connecting at T9 by W makes seki, the life
> of the entire B dragon, consisting of two separate strings,
> must be considered. Since the dragons are not even defined
> during make_worms, it is clear that this is a dragon problem,
> not a worm problem.
I agree completely. I was actually thinking about a hypothetical case
like century2002:180, except with the Q10 filled, such that if defender
began passing at the right point there was no tactical attack. The
problem as given is clearly a problem for the owl code, however, since the
w string can actually be captured, even though it leaves the b dragon with
a dead eyespace.
>
> There are some ad hoc seki patterns in patterns.db, mostly
> in the corner, and one approach would be to try to expand
> that section. Another more ambitious approach would be to
> write a new function to try to recognize positions like
> this. But such a function would belong in owl.c, not
> reading.c.
Again, I agree; besides, the pattern database always needs tuning.
Evan Daniel