[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gnugo-devel] attack1() patch

From: Gunnar Farneback
Subject: Re: [gnugo-devel] attack1() patch
Date: Sun, 24 Nov 2002 20:00:48 +0100
User-agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/20.7 (sparc-sun-solaris2.7) (with unibyte mode)

Evan wrote:
> Examining ld_owl:182 gives an improved outlook for the patch.  It is
> actually only a depth problem after the patch (one call to
> increase_depths is sufficient to fix it). I had been worried that
> some complex interaction was occuring between the reading code and the owl
> code, but it appears that is not the case.  The question now becomes what
> the desired behavior for the reading code is.  Clearly the long-term
> answer is a more complex ko handling system.

Yes, a ko system which keeps track of the number of (external) ko
threats either side must ignore in order to win the ko would be useful
(but more difficult to deal with due to the added complexity). It is
almost always acceptable to say that if more than four (or maybe
three) ko threats are needed the ko is lost.

> Short term, however, the
> question is what to do about the following cases:

> A:
> (reading:55)
> +-----
> |.X.XO
> |OOOO.

Unless the outside O stones can be attacked (in ko) it would be best
if X were considered tactically dead.

> B:
> +-------
> |.X.X.XO

O can attack with good ko, unless the outside O stones have a liberty
problem. X can defend with WIN.

> C:
> (reading:132)
> +-----------
> |.X.X.XXX.XO

O can attack with good ko, X can attack with bad ko. Usual condition.

> The question is how should the reading code return for each of the three
> cases?  Currently, with w to play and able to take the ko, it returns KO_A
> for all three cases.  However, this answer is only fully correct for case
> B.  In case A, the defender can delay capture but cannot win the ko.  In
> case B, it is a simple ko.  In case C, defender must win the ko twice in
> order to save the stone under attack. 

Yes, with an improved ko system.

> The fourth case is the one where
> the reading code cannot see a way to win the ko, but the owl code can.

So how does this fourth case look? You never showed us.


reply via email to

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