[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [gnugo-devel] move valuation
From: |
Inge Wallin |
Subject: |
Re: [gnugo-devel] move valuation |
Date: |
Tue, 13 Nov 2001 11:49:37 +0100 (MET) |
Arend wrote:
> 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
is really caught but if b is found as a threat to save the two white
stones, it will be.) This will give:
total value = 7 + 0.5 * 5 = 9.5 (just what you valued the move to)
> 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
generates a followup value of 1 point should be simple to generate.
For a number of examples like this, look in patterns/endgame.db.
> 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.
But the real weakness is (as I also said above) that there is no real
notion of sente and gote sequences.
-Inge
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