gnugo-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gnugo-devel] endgame tuning


From: Gunnar Farnebäck
Subject: Re: [gnugo-devel] endgame tuning
Date: Fri, 15 Oct 2004 04:21:53 +0200
User-agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.9) MULE/5.0 (SAKAKI)

I wrote (on September 9):
> > +Pattern CE34
> > +# evand New pattern. (3.7.1)
> > +# see endgame:920
> > +
> > +?OO
> > +...
> > +O*X
> > +
> > +:8,OXe,terri(1)
> 
> Should also eventually be solved by influence tuning.

I'll make an attempt to make influence tuning somewhat less mystic to
other people than me and Arend by showing how to solve this problem.
For reference I'm using GNU Go 3.6-pre2 in this analysis.

Start by firing up view.pike on testcase endgame:920, e.g. by running
"pike view.pike endgame:920" in the regression directory.

We see from the first view of move values that filling dame at P15 is
valued highest with 0.17 points while the correct move at C4 is valued
slightly lower with 0.16. The real problem is of course that C4 is
worth a full point and thus should be valued about 1.0.

Now click on C4 to get a list of move reasons and move valuation
information. Everything looks okay except that change in territory is
0.00 rather than 1.00 as it ought to be.

We can confirm this by choosing the "delta territory for..." button
and again clicking C4. Now B5 should have been marked as one point of
change in territory, but it's not.

Next step is to enter the influence debug tool. Press the "influence"
button, followed by "black influence, dragons known", and "territory
value". This shows the expected territory if black locally moves first
everywhere (thus "black influence"). Here we can see that B5 is
incorrectly considered as 1.0 points of white territory.

We can compare this with the territory after a white move at C4 (still
assuming that black locally moves first everywhere after that) by
pressing "after move influence for..." and clicking C4. This looks
identical, as expected since delta territory was 0, but here it is
correct that B5 is 1.0 points of territory for white.

The most straightforward solution to this problem is to add a
non-territory pattern, saying that white can't get territory on B5 if
black moves first. 

Pattern Nonterritory56

...
X.O
?O.

:8,t

eac
XbO
?Od

;oplay_attack(a,b,c,d,d)

>non_xterritory(e);


In these patterns it's always assumed that O moves first and thus it
says that X can't get territory at B5 (e in the pattern). Now we need
to be a bit careful however since after O plays at a and X cuts in at
b, it may well happen that O needs to defend around d, allowing X to
cut at c, possibly making the nonterritory assumption invalid. It's
difficult to do this entirely accurate, but the constraint above is
fairly conservative and should guarantee that a is safe in most,
although not all, cases.

/Gunnar




reply via email to

[Prev in Thread] Current Thread [Next in Thread]