FW: [gnugo-devel] a question about conn.db

[Portela Fernand]

Upon Dan's suggestion, a bit of documentation. This is what I observed
in a specific case, I haven't witnessed the move valuation problems
mentioned by Gunnar, so I can't describe them.

/nando

- documentation about special experimental connection patterns

Index: patterns/conn.db
===================================================================
RCS file: /cvsroot/gnugo/gnugo/patterns/conn.db,v
retrieving revision 1.33
diff -u -r1.33 conn.db
--- patterns/conn.db    2 Jan 2003 00:23:29 -0000       1.33
+++ patterns/conn.db    28 Jan 2003 16:36:31 -0000
@@ -1481,6 +1481,32 @@
 ####################################################################
 #
 # CC5xx - experimental connection patterns
+#
+####################################################################
+#
+# Note about patterns CC501, CC502, CC502b, CC511
+#
+# In theory, these patterns go against the connection policy that the
+# involved strings must be tactically stable (not capturable) and
+# consequently, they should not be needed at all. In practice though,
+# problems arise with the optics/owl analysis when such strings aren't
+# amalgamated. An example (see owl:50)
+#
+# +------
+# |...X.O
+# |XXX.XO
+# |.OOXXO
+# |O.OOOO
+#
+# In the absence of the mentioned patterns, the topmost X stone would
+# _not_ be amalgamated with the others, because all attempts at
+# defending these kosumi connections result in a tactical capture of
+# the whole string, thus a successful cut.
+#
+# As a consequence, the owl code would be run against separate targets,
+# and in the above case, it would even fail to find a way to kill the
+# topmost X stone (the lack of context is then responsible for the 
+# optics/owl code not being able to return vital points)
 #
 ####################################################################