gnugo-devel
[Top][All Lists]
Advanced

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

Re: [gnugo-devel] Regression results for the large scale patch


From: Arend Bayer
Subject: Re: [gnugo-devel] Regression results for the large scale patch
Date: Fri, 8 Aug 2003 14:39:08 +0200 (CEST)


On Wed, 6 Aug 2003, Stéphane Nicolet wrote:

> Here are the regression results (against 3.4) for the large
> scale capture patch posted in
> <http://mail.gnu.org/archive/html/gnugo-devel/2003-07/msg00209.html>

Thank you for posting this. I must say I am quite impressed by the
PASSes :) The ones I looked at were all important, and would be
difficult to solve without a systematic approach as you are doing.
Unfortunately, some of the FAILs are also impressive :(
(I sometimes differ a little with your judgement on the FAILs, see
a few examples below. )

Capturing on a larger scale has 2 problems: The objective one is that
it may leave a lot of aji that will cost points later on in the game.
The GNU Go specific one is that we too often see gnugo let escape
dead groups due to owl misreads.

[Btw: Self-play is, I think, not a good test for the large_scale patch.
As the opponent is running almost the same life-and-death analysis, it
will believe that the group is dead. Hence, the large_scale patch gets
the benefits of large capture without its risks.]

No my suggestion: It occurred to me that one could distinguish the good
large scale captures from the bad ones by checking whether the owl
reading got more complicated.
To make this precise, we should store the number of owl nodes for all
initial owl readings in the dragon_data2 struct. Now when you issue an
owl_does_attack call, and it takes more owl nodes than the initial reading,
we can decide to distrust this attack.

So:
owl_attack/defend should pass back the number of nodes needed to the
caller.
Before calling owl_does_attack in your code, the maximum allowed number
of owl nodes should be shrunk.
owl_does_attack should pass back result_certain (as owl_attack/defend
already do).

There are some issues with (persistent) caching, but I think they can be
solved.

Arend

> 2 unexpected FAIL: Correct 'Q18|S16', got 'P16'
>     http://www.public32.com/regress/?arion:2
>
>     Don't know. If P16 indeed kills R17,
>     then it's OK. I'm not strong enough to tell.

If W responds at O15, then the exchange P16-O15 has helped white not
black.

> 64 unexpected FAIL: Correct 'B13|C13|C12|E14|D14', got 'B12'
>     http://www.public32.com/regress/?strategy2:64
>
>     Maybe not a fail. Doesn't seem different from B13.

Yes B13 should be added to the list of correct answers.

> 89 unexpected FAIL: Correct '(D16|B7|G13)', got 'H11'
>     http://www.public32.com/regress/?strategy2:89
>
>     Maybe not a fail. H11 has more effect in the center, but
>     leaves more freedom for the white stones.

No, H11 leaves too much aji. Even if the white group cannot live
(and I am sure it could live against gnugo after B H11), white
will be able to exploit the aji to conveniently live inside the black
moyo.

> 440 unexpected FAIL: Correct 'O2', got 'N3'
>     http://www.public32.com/regress/?nngs:440
>
>     Don't know. O2 captures the corner more tightly,
>     but N3 sort of protects the cut in O4.

N3 looks a little inefficient to me, doing neither of the two things
cleanly.







reply via email to

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