Re: [gnugo-devel] move valuation

[Gunnar Farneback]

Arend wrote:
> Also, one can work around this with follow_up values, which as I
> understand GnuGo does rather rarely.

Followup values are awarded from patterns and for detected threats to
attack, defend, owl_attack, or owl_defend. There are certainly many
positions where we fail to find a followup value, but I wouldn't call
them rare.

> Of course there are other things to worry about first; still I feel
> that e.g. GnuGo's reluctance to jump into an opp's moyo (unless forced
> to do so by patterns like LE14/LE15 with fixed values -- which quite
> often produce rather inefficient moves as well) partly comes from the
> same problem: It does not give the chance to jump further into opps
> moyo enough value.

This is mainly a problem with the identification and valuation of
"area" and "moyo". Those heuristics are not good enough for valuation
purposes, although they're doing a reasonably good job elsewhere (e.g.
helping to determine where it's safe to move). I'll have to come back
to this some other time.

Inge wrote:
> > The double sente value computation is probably not very good.
> 
> Indeed it is not, since the two players in a a double sente situation
> often has to play on different intersections.

That has very little to do with the valuation.

> Yes, like I describe above.  It was me that introduced the followup
> and reverse_followup values and my intention was that we produce them
> for lots of situations by patterns or by code. 

As I recall it you did the split between followup_value and
reverse_followup_value and added code to look harder for them. The
concept of followup_value was included in the current move valuation
scheme from the very beginning.

Arend wrote:
> > No.  It will be valued as 7 points of territory value and 5 points of
> > followup value.  (In this case, I am not sure that the followup value
> Well, these 7 pts are correct according to the principle stated by Gunnar
> that the position is valuated "with X playing first in each local position".

Yes, the "territorial_value" should be 7 points.

> > is really caught but if b is found as a threat to save the two white
> > stones, it will be.)  This will give:
> No it is not.

The code looking for attack/defense threats misses this move, but it
won't be hard to modify the code so it's found.

> >   total value = 7 + 0.5 * 5 = 9.5 (just what you valued the move to)
> Yes. Maybe Gunnar misexplained slightly in stating that follow_up values
> etc. are only used to determine sente/gote relationships?

I guess I oversimplified. Followup and reverse followup values are
always taken into account when computing the final move value, not
only when those are big. More precisely this is done in the function
value_move_reasons() in move_reasons.c. The relevant part of the code
(simplifed and cleaned from comments and trace output) looks like

  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);
  }

I'm not certain the formula for the addition of the
reverse_followup_value makes all that much sense. It has been tweaked
a few times to workaround certain observed problems, which may or may
not be relevant today. Clearly it doesn't do a good job with double
sente situations, which are characterized by both followup_value and
reverse_followup_value being large.

> Ultimately, but that is a bit of work, I would suggest the following
> approach (although it could also cause a performance problem):

The performance problem is one key issue. Especially considering:

> Of course, if a move is produced e.g. by owl, it would be owl's task
> to produce the/some follow-up moves.

and the fact that the owl code is main time consumer. The second key
issue is that if e.g. the owl code is doing a bad analysis, you can
get further off by this approach than without it, giving a worse
valuation than before.

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. 

> Actually, while my approach might be quite a bit of work, it might still
> be less work than producing those thousands of necessary follow-up value
> patterns.

I think you're too pessimistic. A large class of followup values can
be found with relatively small amounts of code already today.

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

/Gunnar