Re: [gnugo-devel] attack1() patch

[Evan Berggren Daniel]

On Sat, 23 Nov 2002, Evan Berggren Daniel wrote:

> On Fri, 22 Nov 2002, Evan Berggren Daniel wrote:
>
> > This patch solves reading:55.  In the testcase, the defender can make a
> > group with one eye and one liberty in ko.  The reading code does not
> > understand that the defender cannot win the ko no matter what.  This patch
> > makes attack1() count such cases as wins by checking whether the defender,
> > given infinite moves, could actually defend.  (Defender needs more than
> > one chance for cases like reading:132 where he must win the ko more than
> > once, but can win eventually.)  Of course, this has a small performance
> > penalty (reading nodes in reading.tst from 97435 to 97799).
> >
> > I am running a full regression suite now, and will post results if more
> > than reading:55 changes.
>
> So far one fail in ld_owl:182 (a tripod group ko problem).  It seems
> likely to be real.  I'll see if I can get something better worked
> together, but the patch is probably a bad idea as it stands.

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.  Short term, however, the
question is what to do about the following cases:

A:
(reading:55)

+-----
|.X.XO
|XXXOO
|OOOO.

B:

+-------
|.X.X.XO
|XXXXXOO
|OOOOOO

C:
(reading:132)

+-----------
|.X.X.XXX.XO
|XXXXXOOXXOO
|OOOOOOOOOOO


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.  The fourth case is the one where
the reading code cannot see a way to win the ko, but the owl code can.  If
this is the case, the I believe the ko must be won a sufficiently large
number of times (dependent on how far ahead it is) that calling it an
unconditional win and valuing the moves accordingly is probably
acceptable.  My patch corrects the behavior of case A, but breaks case D.
The change of ld_owl:182 from a correct answer to a problem of
insufficient depth is (I think) a result of the tactics code being unable
to see a win for defender when reading is that deep, but the owl code
still understanding the situation.  I think, however, that the difference
in play that results from applying the patch will be minor.  I think on
balance the behavior with the patch is more correct, but neither behavior
is completely so.

Thanks

Evan Daniel