[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [gnugo-devel] min_value revision
From: |
Gunnar Farneback |
Subject: |
Re: [gnugo-devel] min_value revision |
Date: |
Thu, 30 Jan 2003 20:53:41 +0100 |
User-agent: |
EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/20.7 (sparc-sun-solaris2.7) (with unibyte mode) |
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