gnugo-devel
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]