gnugo-devel
[Top][All Lists]
Advanced

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

Re: [gnugo-devel] another semeai patch


From: Paul Pogonyshev
Subject: Re: [gnugo-devel] another semeai patch
Date: Wed, 14 Jan 2004 20:45:45 +0000
User-agent: KMail/1.5.94

Dan wrote:
> Paul wrote:
> > In this semeai position, min_eyes(&probable_eyes_b) happens to be 13.
> > This is due to tactical attack on the first dragon.  So, instead of
> > taking the test down, i propose to replace "==" with ">=".  The test
> > is actually there for performance reason: no need to try filling dead
> > eyeshapes if there are none.
>
> After such a change there is the following breakage:
>
> ./regress.sh . trevora.tst
> 370 unexpected PASS!
> ./regress.sh . nngs.tst
> 820 unexpected FAIL: Correct 'J13|L9', got 'D14'
> ./regress.sh . semeai.tst
> 59 unexpected PASS!
> 60 unexpected FAIL: Correct '0 0 PASS', got '1 1 H5'
> ./regress.sh . strategy4.tst
> 155 unexpected FAIL: Correct 'D18', got 'E16'
> ./regress.sh . ninestones.tst
> 560 unexpected PASS!
> ./regress.sh . 9x9.tst
> 30 unexpected PASS!
> 120 unexpected FAIL: Correct 'F1', got 'B1'
>
> [skipped]
>
> What we get is two new unexpected fails at nngs:820 and
> strategy4:155.

I didn't look into this, but i suspect that the failes are caused by
increased number of nodes.  That is, semeai code most likely runs out
of nodes in those tests now, which is not something good for accurate
reading.

The logic of the patch is like this: "when semeai code doesn't know
what to do, and there is a dead eyeshape (but not two or more certain
eyes), try to fill it".  Changing "==" to ">=" effectively removes the
"no two certain eyes" cutoff and will of course waste nodes in certain
positions.

> It seems to me that this breakage is acceptable, but we
> might want to take a look at whether something can be
> done about strategy4.

So, maybe we should rather try to make `probable_eyes_b' contain more
accurate results (and not waste semeai nodes).  I will regress the
change i proposed: ignoring lunches for dragon B which are part of
dragon A (like we do for dragon A's lunches which are part of B).

Paul




reply via email to

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