[gnugo-devel] min_value revision

[Evan Berggren Daniel]

When evaluating moves with high minimum values, Gnu Go currently evaluates
the moves, and, if this evaluation is below the min_value for that move,
raises the valuation to the minimum value.  This results in problems with
testcases like arend:15 (approaching a hoshi stone from the correct side),
arion:1, and trevorc:1180 (blocking a 3,3 invasion).  In all three cases,
gnugo properly understands the relative value of two moves, but that
information is lost because of high minimum values.  As a result, Gnu Go
chooses at random between the moves.

This patch makes a very simple attempt to treat minimum values more
correctly.  It linearly transforms the value of a move from something in
the range 0 - min_value + 2 to the range min_value - min_value + 2.  The
result is that Gnu Go's decisions about the relative values of the moves
are kept, but the minimum value is also observed.  However, it also
appears to hurt tunings between moves with a high min_value and moves
without.  I am not sure what the correct approach is, but I think the
problem needs addressing.

Thanks

Evan Daniel



Here are the results:

nngs1:20     FAIL    accidental
nngs1:27     PASS    accidental
arion:1      PASS    properly solved
manyfaces:1  PASS    accidental
niki:1       FAIL    accidental
trevorc:1180 PASS    properly solved
arend:15     PASS    properly solved
handtalk:1   PASS    accidental
safety:5     FAIL    accidental

Here an accidental result is one that is the result of an increase in
value of a move with a min_value to something greater than a move without,
and a proper solution is where Gnu Go now correctly distinguishes between
two moves with equal min_value.


Index: engine/value_moves.c
===================================================================
RCS file: /cvsroot/gnugo/gnugo/engine/value_moves.c,v
retrieving revision 1.80
diff -u -d -r1.80 value_moves.c
--- engine/value_moves.c        28 Jan 2003 12:12:19 -0000      1.80
+++ engine/value_moves.c        30 Jan 2003 16:20:37 -0000
@@ -2670,10 +2670,11 @@

   /* Test if min_value or max_value values constrain the total value.
    * First avoid contradictions between min_value and max_value,
-   * assuming that min_value is right.
+   * assuming that min_value is right, always allowing for a 2-pt
+   * range.
    */
-  if (move[pos].min_value > move[pos].max_value)
-    move[pos].max_value = move[pos].min_value;
+  if (move[pos].min_value + 2 > move[pos].max_value)
+    move[pos].max_value = move[pos].min_value + 2;

   /* If several moves have an identical minimum value, then GNU Go uses the
    * following secondary criterion (unless min_value and max_value agree, and
@@ -2682,7 +2683,17 @@
    */
   if (move[pos].min_value < 25)
     move[pos].min_value += tot_value / 200;
-  if (tot_value < move[pos].min_value
+
+  /* Soft minimum value, with linear scaling.  This is so that equal
+   * minimum values, particularly from J patterns, do not destroy
+   * the distinction between moves.
+   */
+  if (tot_value < move[pos].min_value + 2
+      && move[pos].min_value > 10) {
+    float scale = tot_value / (move[pos].min_value + 2);
+    tot_value = move[pos].min_value + 2 * scale;
+    TRACE("  %1m:   %f - scaled minimum accepted value\n", pos, tot_value);
+  } else if (tot_value < move[pos].min_value
       && move[pos].min_value > 0) {
     tot_value = move[pos].min_value;
     TRACE("  %1m:   %f - minimum accepted value\n", pos, tot_value);