[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[gnugo-devel] (no subject)

From: Arend Bayer
Subject: [gnugo-devel] (no subject)
Date: Thu, 8 Nov 2001 14:20:07 +0100 (CET)

Dear Gnugo, 

I downloaded GnuGo 3.0.0 just recently, I quickly got interested
in tuning and improving it, and if I find time to do it, I would be
willing to help a bit. As I am definitely worse as a programmer than as
a Go player, I will probably be more useful in tuning/revising move
evaluation etc.

Before I start trying out specific patches in the pattern databases I have
a general question.
If I didn't misread shapes.c, the classifications j and t imply a fixed
move value. I (reluctantly :-) ) accept that GnuGo needs the help of
minimum values (although I came across a couple a couple of blunders that
were caused by too unspecific patterns with a hand-inserted minimum
value), but I do not understand the need of maximum values. The j and t
are used very frequently for edge josekis, which are often related to
(strategic) attacks and defenses, and GnuGo does a reasonable job in
guessing these values, sometimes (correctly in my judgement) resulting
in a higher value than 15 resp. 20.  The fixed value throws away this
valuation, and instead lets GnuGo toss a coins when deciding
between different j or t patterns. Shouldn't we rather trust GnuGo
than the coin?

I tried this out on GnuGo-3.0.0. I simply deleted the max_value evaluation
from move_reasons.c; also, I changed the comparison with the minimum value
as follows:
<   if (tot_value < move[m][n].min_value && move[m][n].min_value > 0) {
<     tot_value = move[m][n].min_value;
>   if (tot_value < move[m][n].min_value + tot_value/100
>       && move[m][n].min_value > 0) {
>     tot_value = move[m][n].min_value + tot_value/100;
(So if GnuGo has two choices with identical mimium value, it still trusts
its own judgement a little.)

The patched version didn't fail (nor improve) in a single regression test.
When I let my patched version replay GnuGo games, there were
very few differences, and in most cases my patch chose the better move
(according to my judgement). More importantly, my change would enable a
serious tuning of Fuseki patterns and judgements.

(Btw, an immediate drawback of this change is that GnuGo's play becomes mostly
deterministic, one should probably take care of.)

So I would suggest to drop the maximum_values from the j and t patterns,
and retune fuseki.db patterns accordingly; moves that are regularly
overvalued by GnuGo would need a correcting negative shape value.

So, what are your opinions on this? What made you originally introduce
the maximum value for these patterns?


(Reply via gnugo-devel if you like.)

|                             Arend Bayer                             |
|                          Breite Stra?e 37                           |
|                             53111 Bonn                              |
|                            0228-9813803                             |
|                         address@hidden                          |

reply via email to

[Prev in Thread] Current Thread [Next in Thread]