[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [gnugo-devel] move valuation
From: |
Arend Bayer |
Subject: |
Re: [gnugo-devel] move valuation |
Date: |
Tue, 13 Nov 2001 12:53:58 +0100 (CET) |
> > 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
Re: [gnugo-devel] Patch arend_1_14.2 -- Missing endgame pattern, Daniel Bump, 2001/11/12
[gnugo-devel] Patch arend_1_14.2 revised, Arend Bayer, 2001/11/12