Re: [gnugo-devel] move valuation

[Arend Bayer]

> > So the following is just a theoretical discussion, but since I raised
> > that matter I feel I should explain why I think so: Let's look at the
> > following position:
> > |..XXXXXXXXX...
> > |XXXOXOOOOOXXXX
> > |XOXOXO.O.OXOOX
> > |.OaObO.O.OcOOX
> > +--------------
> > First note that all moves here are gote.
> > Your method values a white move at b with 7 pts (after white moves there,
> > black will be assumed to play at a). A white move at c is worth 8 pts.
> 
> 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".

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

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

> > As another example, the move
> > OXXXX
> > O*..X
> > is valued as 1pt by GnuGo (instead of 1.5).
> 
> It is? Have you checked this?  In that case, a simple pattern that
Yes. See also arend.tst:37. Of course it would be easy to generate a
pattern that treats this particular case, and I agree that the
followup_values are a very good improvement. But I don't think it is
manageable to get a large enough database of patterns including their
follow_up values; if you want to specify the follow_up value, you need
to know the surrounding conditions very well.

Ultimately, but that is a bit of work, I would suggest the following
approach (although it could also cause a performance problem):
Alternatively to producing a fixed follow up value, a pattern could
suggest (an) O-followup and (a) X-followup move(s). Then
GnuGo could value these followup-moves himself. To do this, it could
also look for follow-ups for O and X after the O-followup move, and
the same after the X-followup move, and so forth. This followup-followup
could in two ways: 1. The O-followup-helper could explicitly refer to
patterns producing followup-followup-moves. 2. One could do a second
pattern matching looking for moves for O and X, and only looking for patterns
that match now and did not match before.
(Of course, some moves like
OX.
OX*
.O.
---
have to be valued directly by the influence function without looking for
follow_ups, otherwise the algorithm would not stop.) 

After having valued all these possible continuations, there is a
very straightforward algorithm (which I could describe if someone is
interested; but it is just an expansion of the principle "If there is
a sente vs gote position assume that the sente will be played eventually,
and count territories accordingly.)

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

> > Also, one can work around this with follow_up values, which as I
> > understand GnuGo does rather rarely.
> 
> 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.  Examples right now are
> that threats to save or capture a string gets followup values and a
> number of patterns in endgame.db are assigned to only provide followup
> values for common situations.  There should be a lot more of them.
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.

> But the real weakness is (as I also said above) that there is no real
> notion of sente and gote sequences.
I think my approach could settle this problem as well. 
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.)

I might experimentally try to implement the approach I describe above,
starting with first line endgame patterns. But definitely not
before I got to know GnuGo a little better -- it is still less than 2
weeks ago that I downloaded it :).

-Arend