Re: [gnugo-devel] move valuation

[Arend Bayer]

>   tot_value = move[pos].territorial_value + move[pos].strategical_value;
>   if (tot_value >= 0.5) {
>     tot_value += gg_min(1.1 * tot_value, 0.5 * move[pos].followup_value);
>     tot_value += gg_min(0.75* tot_value, 
>                       0.4 * move[pos].reverse_followup_value);
>   }
Yes, I read this. I think technically more correct should be the following
formula:

if ( (move[pos].followup_value > tot_value
                        + 0.5*move[pos].followup_value
                        + 0.5 * move[pos].reverse_followup_value) &&
     (move[pos].reverse_followup_value > tot_value 
                        + 0.5*move[pos].followup_value
                        + 0.5 * move[pos].reverse_followup_value) )
tot_value = 2*tot_value + move[pos].followup_value
/* If a move is double sente, then play it as soon as possible, i.e. as soon
   as it is big enough as gote. */
else {
  tot_value += gg_min(
    0.5 * move[pos].followup_value + 0.5 * move[pos].reverse_followup_value,
    1.1 * tot_value + move[pos].reverse_followup_value,
    tot_value +  move[pos].followup_value);
}

To explain this:
The folklore rule "A sente play is worth twice as much" should actually say
"A reverse sente play is worth twice as much".
Usually (i.e. everything gote), the value is
        tot_value + 0.5*followup_value + 0.5*reverse_followup_value.
If it is reverse sente, the rule means we have to take
        2* (tot_value + 0.5*followup_value) instead.
A sente play can be played as soon as its value as gote (which is
tot_value + 0.5*followup_value + 0.5*reverse_followup_value) is big enough,
but of course it should be played as late as possible to leave it as a ko
threat; so one plays it just before it gets big enough that the opponent
could take it, and therefore I like Gunnar's choice of 1.1 * tot_value.
(Of course, for the opponent, the value of the move is
       2*tot_value + reverse_followup_value.)
However, a double sente should be played as
soon as possible, that is, as soon as its value as gote is big enough,
which is (reverse sente->doubling!) 2* (tot_value + 0.5*followup_value).

(If you think this is worth trying out I can send it as a patch of course.)

> > Ultimately, but that is a bit of work, I would suggest the following
> > approach (although it could also cause a performance problem):
>
> In general I agree that the only way to get a truly accurate move
> valuation is to actually play out the local positions. However, I
> don't think the engine is mature enough for that approach yet, neither
> with respect to speed, nor accuracy. 
Yes, I agree in general as well :) But a pattern like

OX.
OXa
.*.
---
O_followup(a)

could make sense today already? Also, the X_followup moves could help
saving time by using opponent's thinking time. (I think you have
discussed that before on the list.)

> I think you're too pessimistic. A large class of followup values can
> be found with relatively small amounts of code already today.
Maybe, but sometimes it is simply impossible to guess the followup-values
in a pattern, see the example above. Also, just for a 2nd line endgame
hane, you would need a couple of patterns to compute the followup-values.

> > Also it should cope with the problem that so far GnuGo does not check
> > whether a move that looks good and has a huge follow_up value is
> > actually worth s.th. if the opponents answers it.
> > (Like playing into a knight's move:
> > .X..
> > ..*O
> > ..X.
> > ....
> > ----
> > which is bad aji keshi.)
> 
> As you can see in the formula above, GNU Go doesn't play a move just
> because it has a huge followup value. This is probably a problem with
> the territorial_value estimation, which requires tuning.
But I can hardly imagine a territorial_value estimation that will give
a negative result here before you add the X answer (and a negative value
would be correct here).

Another example I have in mind is the wedge into an iken tobi: GnuGo plays
it too often (and is afraid of it as well), as it disconnects the two
stones, thus creating two weak groups. But of course you cannot estimate
the result of the wedge without considering the (usually bad) result:
.....
.OX..
.XOO.
oXX.o
But again, I agree that this is too too optimistic to expect GnuGo to do
this in the near future.

-Arend