Re: [gnugo-devel] (no subject)

[Gunnar Farneback]

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

That's perfectly fine. We certainly could use help from more strong
players in this area.

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

There are essentially two reasons for this:
* Due to pecularities of the influence function, certain fuseki moves
  can be wildly overvalued. This can have very bad consequences.
* Increase the variance in GNU Go's play.

However, both these arguments really only apply to the fuseki. For
edge joseki I would say GNU Go is generally quite capable of choosing
the right variation. An extremely good example of this is test case
strategy2:77, where GNU Go wants to play H3 among a selection of moves
to connect the stones at D2 and F3 to the main body of stones. GNU Go
values this connection, which owl defends the stones to the left, to
about 26 points, with somewhat smaller values for the suboptimal moves
like H2, G3, G2, and J2. However, since H3 happens to match a j
pattern it is devalued to 20 points, forcing GNU Go to instead play at
H2 (which is not a j pattern). This obviously doesn't make sense.

A solution to this problem which I have considered is to only enforce
the maximum values while doing matching in joseki.db and fuseki.db
(the edge joseki patterns are in patterns.db). Actually the
possibility to do this was one of the primary reasons why I broke out
fuseki.db from patterns.db in the first place. It's not exactly a
beautiful solution, but I think it's the best we can do in the short
term.

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

Quite a lot I would say. The random contribution is between 0 and
0.01, so if the unthresholded values differ by more than one point,
then the randomness will be completely ineffective.

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

This is very important in the fuseki but of little consequence later
in the game.

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

This is pretty much what one would want to do, but it has one
significant problem. If the influence function or the dragon safety
evaluation is changed, the tuning could quickly fall apart. I did
actually try this approach at one time, fairly early in the 2.7.xx
series, but there was no way I could keep it in tune when other things
changed.

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

Mainly a problem with certain joseki, and sometimes non-joseki,
variations being consistently chosen.

My opinion is
* Remove the max values for j and t patterns except in the fuseki.
* Maximum values have valid uses also outside the fuseki, just not for
  j (and t) patterns.
* Tuning the fuseki just with shape values is not sufficiently robust.
* Too deterministic play is bad, at least in the fuseki.

Dan wrote:
> I think you understand the issues with the j and t patterns
> very well. Your patch might be OK. Regarding the indeterminacy
> there is still some indeterminacy from the fuseki database.
> I imagine there will now be some further discussion of 
> whether or not we need the further indeterminacy of the 
> j and t patterns in the list.

Not worth much discussion. If we are agreed that deterministic play is
bad (because it can be boring for human opponents and it allows
opponents to engineer traps which GNU Go would always fall into), then
it's a simple observation that one can immediately break out of the
wholeboard fuseki database by playing some non-standard move, e.g. J7,
at the first opportunity. Clearly we need indeterminacy also in the
rest of the fuseki. For non-standard board sizes we don't even have a
fullboard fuseki database, and we don't want to play deterministically
there either.

/Gunnar