gnugo-devel
[Top][All Lists]
Advanced

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

[gnugo-devel] connection tuning


From: nando
Subject: [gnugo-devel] connection tuning
Date: Sun, 16 May 2004 04:03:11 +0200

Hi again,

A solution proposal to a small annoying problem I've noticed in quite a few
games (last time was today on KGS). "Annoying", because reading such kind
of cuts, like in connection:111, seems damn easy. Regression breakage :

connection:111  PASS 0 [0]
arion:6         PASS E19 [E19|F19|F18]
global:1        FAIL A4 [B3]
gunnar:53       PASS S17 [S17]         (same as connection:111)

The failure seems accidental. The patched version awards 4 more points of
territory for A4 due to a small change in the break-in analysis. IMHO, both
CVS and the patched version are misreading, but CVS only hits the depth
limit, while the patched version hits both depth and nodes limits.

Impact on performance is negligeable (less than +/- 0.05% in all categories)

nando

- connection tuning

Index: readconnect.c
===================================================================
RCS file: /cvsroot/gnugo/gnugo/engine/readconnect.c,v
retrieving revision 1.77
diff -u -r1.77 readconnect.c
--- readconnect.c       29 Apr 2004 23:59:21 -0000      1.77
+++ readconnect.c       16 May 2004 01:37:54 -0000
@@ -2555,10 +2555,28 @@
          if (verbose > 0)
            gprintf("%o%1M -0.2, adjacent to defender string with at most two 
liberties\n", move);
        }
+       /* The code above (in the 'board[pos] == other' branch) makes
+        * perfect sense for the defender, but has a tendency to
+        * overestimate solid connection defenses when the attacker's
+        * stones happen to be in atari, specially when capturing some
+        * defender stones instead would help just as well, if not better.
+        * The following code compensates in such kind of situations.
+        * See connection:111 and gunnar:53 for example.
+        */
+       if (!connect_move && countlib(pos) == 1
+           /* let's avoid ko and snapbacks */
+           && accuratelib(move, other, 2, NULL) > 1) {
+         int adjs[MAXCHAIN];
+         float bonus;
+         bonus = 0.6 * chainlinks2(pos, adjs, 1);
+         distances[r] -= bonus;
+         if (verbose > 0)
+           gprintf("%o%1M -%f, capture of defender string\n", move, bonus);
+       }
       }
     }
     if (adjacent_to_attacker
-       && color != color_to_move
+       && !connect_move
        && is_edge_vertex(move)) {
       distances[r] -= 0.1;
       if (verbose > 0)




reply via email to

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