gnugo-devel
[Top][All Lists]
Advanced

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

[gnugo-devel] bugfix in dragon_escape()


From: Portela Fernand
Subject: [gnugo-devel] bugfix in dragon_escape()
Date: Sat, 28 Dec 2002 00:04:45 +0100

As mentioned in a previous post, I've been trying various things around
escape values lately. Today, I was reading the code in dragon.c when I
noticed what seemed to be an inconsistency around line 1824. The current
code in CVS does something like this :

  if (a && (b || (b && c))

Obviously, c just does nothing here. By comparing with the code above these
lines and by reading the comment which describes the expected behavior of
this portion of code, it's easy to infer that a copy/paste mistake occured
here.

As expected, the regression breakage is large, but not as much as I would
have imagined: 9 PASSes and 10 FAILs. Since this isn't a tuning, I've only
taken a (very) quick look at these :

nngs1.tst:48        PASS    Looks lucky.
lazarus.tst:4       PASS    Looks good.
trevorb.tst:960     FAIL    Serious, but looks fixable.
strategy2.tst:90    FAIL    I don't know, G13 is maybe acceptable.
trevor.tst:412      FAIL    Barely passed previously, but serious anyway.
nngs.tst:500        PASS    Looks very good.
global.tst:26       FAIL    Looks bad.
global.tst:34       PASS    Not sure, maybe good.
13x13.tst:7         FAIL    *sigh*
13x13.tst:65        FAIL    Looks bad.
nngs3.tst:230       PASS    IIRC, it's only a persistent cache effect which
                            just disappeared. In conclusion, lucky.
nngs3.tst:310       PASS    I'm not convinced, but it might be ok.
nngs3.tst:390       FAIL    Bad.
nngs3.tst:400       PASS    Looks good.
nngs3.tst:1190      FAIL    C17 looks very bad to me.
strategy5.tst:232   PASS    Not sure, possibly good.
century2002.tst:260 FAIL    R13 looks inferior.
safety.tst:7        FAIL    Very bad.
manyfaces1.tst:90   PASS    Much better.


About the performance : I've run the regressions with Paul's patches, so
I don't know exactly what's the impact of this one. Still, my current
measures show a global 11% improvement in owl nodes over 3.3.13, so I don't
think this patch has any important negative effect on this side.

/nando


- bugfix in dragon_escape()

Index: engine/dragon.c
===================================================================
RCS file: /cvsroot/gnugo/gnugo/engine/dragon.c,v
retrieving revision 1.93
diff -u -r1.93 dragon.c
--- engine/dragon.c     22 Dec 2002 20:07:13 -0000      1.93
+++ engine/dragon.c     27 Dec 2002 18:45:29 -0000
@@ -1822,7 +1822,7 @@
              && board[WEST(ii)] == EMPTY
              && !mx[SW(ii)]
              && (board[SW(ii)] == color
-                 || (board[SW(ii)] == color
+                 || (board[SW(ii)] == EMPTY
                      && ON_BOARD(SOUTH(SW(ii)))
                      && board[SOUTH(SW(ii))] != other
                      && ON_BOARD(WEST(SW(ii)))
@@ -1833,7 +1833,7 @@
              && board[NORTH(ii)] == EMPTY
              && !mx[NW(ii)]
              && (board[NW(ii)] == color
-                 || (board[NW(ii)] == color
+                 || (board[NW(ii)] == EMPTY
                      && ON_BOARD(WEST(NW(ii)))
                      && board[WEST(NW(ii))] != other
                      && ON_BOARD(NORTH(NW(ii)))
@@ -1844,7 +1844,7 @@
              && board[EAST(ii)] == EMPTY
              && !mx[NE(ii)]
              && (board[NE(ii)] == color
-                 || (board[NE(ii)] == color
+                 || (board[NE(ii)] == EMPTY
                      && ON_BOARD(NORTH(NE(ii)))
                      && board[NORTH(NE(ii))] != other
                      && ON_BOARD(EAST(NE(ii)))
@@ -1855,7 +1855,7 @@
              && board[SOUTH(ii)] == EMPTY
              && !mx[SE(ii)]
              && (board[SE(ii)] == color
-                 || (board[SE(ii)] == color
+                 || (board[SE(ii)] == EMPTY
                      && ON_BOARD(EAST(SE(ii)))
                      && board[EAST(SE(ii))] != other
                      && ON_BOARD(SOUTH(SE(ii)))



reply via email to

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