[gnugo-devel] Fixed move values

[Arend Bayer]

Dear Gunnar,

Ok, tuning joseki choices with shape values might be a rather odd idea.
I think, in general I would agree with all that you are saying, but I would
like to draw the line a little earlier. 

There are many moves listed in fuseki.db that I would classify as edge
josekis, and whose values are very context sensitive. Take, e.g.

F501

X......  make 2 space extension on third row combined with approach move
..*..O.
.......
.......
-------

Big part of the value of * is the decrease of the likely territory X will
get in the lower left of its stone, and GnuGo's territory function takes
that into account quite reasonably. Similarly, for Pattern F502 (the same
just with X on the third line instead of 4th), its value depends a lot
on whether it has a strategic effect on X (is X weak?) and O (does it
need the extension?). Again, GnuGo gets reasonable guesses IMHO, and I
don't think we should throw them away. (Getting one weak group sometimes
costs GnuGo maybe 30 pts in a single game, if it happens to spend
a handful of moves reinforcing it later.)
Ultimately, I would also like GnuGo to be able to decide sensibly between
things like high and low enclosure of a 3-4 pt und specific circumstances.

> * Due to pecularities of the influence function, certain fuseki moves
>   can be wildly overvalued. This can have very bad consequences.
Hmm, of course the ultimate solution would be to use these examples
to improve the influence function. E.g. GnuGo always overvalues
the Ogeima shimari from a 3-4pt; why? I would say because it neglects
the possibility invasion point at a:
|........        ogeima shimari
|........
|..O.....
|...a.*..
|........
|........
+--------
However, the same principle applys to all large knight move between 4th
and 3rd line, and taking this invasion point into account might generraly
improve the influence function. This would be a more ambitious project
of course.

> > >   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.
Well, 100 was of course just my random guess, I hadn't looked at the
random contribution yet.


Arend