I wrote: > 1. Tactical reading mistake of a three liberty string causes an > overamalgamation which the semeai reading can't recover from. > STS-RV_1:23 > > 9 O O O . . . > 8 X X O . . . > 7 . X O O . . > 6 X X X O . . > 5 . . X O . . > 4 O O O X X . > 3 . O . X . X > 2 O O . X X X > 1 X X X X . X > A B C D E F > > A8 is considered tactically dead.
This can be solved by further restricting the CC505 (conn.db) pattern to not amalgamate over three liberty strings. This causes no breakage on the regression tests and a minor 0.2% increase of owl nodes. Five STS-RV tests are solved. I'm somewhat suspicious about this change, however. Can someone see a situation where it's likely to cause trouble? > 2. The same thing but for a two liberty string. STS-RV_1:58 > > A B C D E F G H > 19 O . X X O X . X > 18 O . X O O X X X > 17 O O O O O X . X > 16 X X X O X X X X > 15 X O X X O O O O > 14 . O O X O . O . > 13 X . X X O O O X > 12 X X X O . O . X > 11 O O O O O O . X > > A19 is considered tactically dead. Not amalgamating over two liberty strings seems rather excessive. The patch http://trac.gnugo.org/gnugo/attachment/ticket/199/gunnar_7_12.7c.diff detects this particular situation where a nakade effectively changes the two liberty string into a three or four liberty tactical reading. See http://trac.gnugo.org/gnugo/attachment/ticket/199 for more details and other attempts to improve the semeai reading. /Gunnar _______________________________________________ gnugo-devel mailing list gnugo-devel@gnu.org http://lists.gnu.org/mailman/listinfo/gnugo-devel