RE: [gnugo-devel] More on minimum values

[Evan Berggren Daniel]

On Mon, 17 Feb 2003, Portela Fernand wrote:

> Evan wrote:
>
> > Also, I didn't want my patch to impact endgame moves.  Maybe it
> > should, but I wasn't looking for those.
>
> Endgame patterns usually have (min)terri() clauses, not (min)value()
> ones. So they shouldn't be that much impacted anyway.

You're right; I was misremembering.

>
> > Consider the case of two J moves, valued at 24.9 and 25.1.
> > Both get a minimum value of 25. If the current method was extended,
> > the lower valued move, being less than the minimum value, would get
> > an increase in its minimum value of 24.9 / 200 = .125, making it
> > valued at 25.125, higher than the second move.
>
> I believe you are mistaken here (reread the current code or do a test,
> you will see), but anyway, I'm not defending the current mechanism.

Seems I had it backwards.  If there were two min_value parameters at 24.9
and 25.1, then the scenario I described could occur.  This obviously won't
occur normally, but it still doesn't seem like a good thing.

> Arend presented good arguments and also wrote :
>
> > But yes, we should not have two such mechanisms.
>
> Since you also think :
>
> > I see no reason that we couldn't eliminate the current version and
> > replace it with my new version.
>
> Very well then, why not replace it immediately ?

OK, here's a patch.

Thanks

Evan Daniel


Index: engine/value_moves.c
===================================================================
RCS file: /cvsroot/gnugo/gnugo/engine/value_moves.c,v
retrieving revision 1.80
diff -u -r1.80 value_moves.c
--- engine/value_moves.c        28 Jan 2003 12:12:19 -0000      1.80
+++ engine/value_moves.c        17 Feb 2003 16:59:42 -0000
@@ -2675,16 +2675,21 @@
   if (move[pos].min_value > move[pos].max_value)
     move[pos].max_value = move[pos].min_value;

-  /* If several moves have an identical minimum value, then GNU Go uses the
-   * following secondary criterion (unless min_value and max_value agree, and
-   * unless min_value is bigger than 25, in which case it probably comes from
-   * a J or U pattern):
+  /* Linearly scale the move value if it is < min_value.
+   * This makes min_value act as a soft minimum, so that
+   * relative weights of moves are preserved.
+   * This policy is problematic if min_value < scale, so
+   * the current method is to leave the move value alone
+   * in such a case -- essentially, we don't trust the
+   * min_value parameter to be correct to within 2 pts.
    */
-  if (move[pos].min_value < 25)
-    move[pos].min_value += tot_value / 200;
   if (tot_value < move[pos].min_value
       && move[pos].min_value > 0) {
-    tot_value = move[pos].min_value;
+    int scale = 2;
+    if (move[pos].min_value > scale) {
+      tot_value = move[pos].min_value - scale +
+           (scale * (tot_value / move[pos].min_value));
+    }
     TRACE("  %1m:   %f - minimum accepted value\n", pos, tot_value);
   }