gnugo-devel
[Top][All Lists]
Advanced

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

Re: [gnugo-devel] readconnect patch


From: Gunnar Farneback
Subject: Re: [gnugo-devel] readconnect patch
Date: Tue, 06 Nov 2001 22:48:10 +0100
User-agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/20.7 (sparc-sun-solaris2.7) (with unibyte mode)

Tristan wrote:
> > The test case is for white to try to disconnect a black two space jump
> > on the third line. The correct answer is that it can't be
> > disconnected, but GNU Go from current CVS says that it is disconnected
> > as it stands.
> 
> it should say it can be connected and can be disconnected.

Should the program or the test case say that? As far as I can see the
two stones are connected as it stands. GNU Go currently says

K17 and G17 can be connected at J17 (35 variations)
K17 and G17 are disconnected as it stands (21 variations)

which is obviously inconsistent.

By the way, if two strings can't be disconnected, do you require
connect to return PASS as move, or is it allowed to suggest a move,
like J17 above?

> yes, the code can detect that it can be connected, then
> when connection is proved, it can try the disconnecting moves.
> This case is a hard one as I previously said, it requires ip51111
> for the first example, and a simple ip6something function for the
> second case. However, the second case can be simplified considering
> strings linked by protected intersections as connected.

Is a two space jump on the third line really a hard connection
problem? I would have thought the program needs to be able to handle
much tougher ones.

> > |..O......
> > |.OOX.....
> > |.OXX.....
> > |.XOX.....
> > |.XOO.....
> > |.XOXXX...
> > |.OXX.....
> > |.OOO.....
> > |.........
> > 
> > where white to connect is an ipN game for some big N.
> > 
> > I guess I'm missing something, or is this just a too difficult
> > position?
> > 
> 
> Capture of common adjacent strings are treated
> by calling the capture code in Golois.

Notice that in the problem above, just capturing the white stones if
they try to move out doesn't suffice. It's necessary to capture them
in a ladder.

But in general I agree that the tactical reading should be used
wherever it's useful in the connection analysis. The appended patch
let's the readconnect code make use of the full-featured tactical
reading in GNU Go, not only the naive_ladder() function, from a few
places. This solves test cases 3, 35, 47, 56, and 73. It doesn't solve
test case 2 but it comes closer by at least understanding that it's
not disconnected as it stands.

However, this almost certainly destroys any possibilities to keep
track of relevancy zones. The tactical reading has a related "shadow"
concept but this is not quite as strictly computed as the relevancy
zones in the paper. Thus this patch is not intended for CVS.

> You can define gradual games as simple functions,
> you do not need to redefine gradual functions
> for each game.
> here is how it is done in Golois (I am sure it can be
> improved), please ask me the unclear meaning of the
> french words you have problem with:

Uh, sorry, but I'm afraid that would be most of the words in my case.

How large part of connect.tst does Golois pass?

/Gunnar

Index: engine/readconnect.c
===================================================================
RCS file: /cvsroot/gnugo/gnugo/engine/readconnect.c,v
retrieving revision 1.11
diff -u -r1.11 readconnect.c
--- engine/readconnect.c        2001/11/02 22:22:18     1.11
+++ engine/readconnect.c        2001/11/06 21:43:48
@@ -139,21 +139,12 @@
  */
 
 static int connection_one_move(int str1, int str2) {
-  int r;
-  int adj, adjs[MAXCHAIN];
+  int dummy;
   
-  /* Common liberties. */
-  if (have_common_lib(str1, str2, NULL))
-    return WIN;
-
-  /* Common adjacent string in atari, more than one stone, no snapback. */
-  adj = chainlinks2(str1, adjs, 1);
-  for (r = 0; r < adj; r++)
-    if (adjacent_strings(adjs[r], str2)
-        && !snapback(adjs[r]))
-      return WIN;
+  if (board[str1] == EMPTY || board[str2] == EMPTY)
+    return 0;
   
-  return 0;
+  return quiescence_connect(str1, str2, &dummy);
 }
 
 /* If the two strings str1 and str2 can be connected sends back WIN fill the
@@ -554,17 +545,8 @@
     return WIN;
   }
 
-  /* Common adjacent string in atari, more than one stone, no snapback. */
-  adj = chainlinks2(str1, adjs, 1);
-  for (r = 0; r < adj; r++)
-    if (adjacent_strings(adjs[r], str2)
-        && !snapback(adjs[r])) {
-      findlib(adjs[r], 1, move);
-      return WIN;
-    }
-  
-  /* Common adjacent string two liberties, read ladder. */
-  adj = chainlinks2(str1, adjs, 2);
+  /* Common adjacent string which can be captured. */
+  adj = chainlinks(str1, adjs);
   for (r = 0; r < adj; r++)
     if (adjacent_strings(adjs[r], str2))
       if (quiescence_capture(adjs[r], move))
@@ -761,6 +743,7 @@
   SGFTree *save_sgf_dumptree = sgf_dumptree;
   int save_count_variations = count_variations;
   int result = 0;
+  int attack_move = NO_MOVE;
 
   /* We turn off the sgf traces here to avoid cluttering them up with
    * naive_ladder moves.
@@ -768,12 +751,9 @@
   sgf_dumptree = NULL;
   count_variations = 0;
 
-  if (countlib(str) == 1) {
-    findlib(str, 1, move);
-    result = WIN;
-  }
-  else if (countlib(str) == 2)
-    result = naive_ladder(str, move);
+  result = attack(str, &attack_move);
+  if (result != 0)
+    *move = attack_move;
 
   /* Turn the sgf traces back on. */
   sgf_dumptree = save_sgf_dumptree;



reply via email to

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