Re: [gnugo-devel] min_value revision

[Gunnar Farneback]

Evan wrote:
> 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.

Um, that's one of the main points of the minimum values, to increase
the variability in its moves. At least arend:15 and trevorc:1180 can
be solved by better patterns.

> 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.

The minimum values are surely problematic, but this is not the way to
solve it.

/Gunnar