Re: [gnugo-devel] endgame tuning

[Gunnar Farneback]

Paul wrote:

> i remembered the `value' pseudofunction which was only used in
> read_attack.db and read_defend.db. so i rewrote the five patterns
> into two, using short scripts and `terri' and `reverse_followup'
> pseudofunctions in the spirit of `value'.

I can't say I like these much. Better to have proper helpers calling
add_followup_value() etc. directly instead of starting to mess around
with the contents of the pattern struct.

> i think this approach is better, because it
>   - makes it easier to take into account move valuation nuances (i
>     assume most of us would prefer to write a short script rather
>     than add several almost identical patterns)

Not really. The need to do this rather indicates missing mechanisms or
an inappropriate approach to the problem.

>   - makes patterns not so static (especially Arend and Evan used to
>     blame "static knowledge" as far as i remember)

This would still count as static knowledge.

>   - values may depend on worm sizes etc.

This is sometimes useful, primarily for followup values, and today
done with specific helpers, e.g. threaten_to_save_helper().

>   - reduces the size of pattern databases (in the long run, if we
>     accept it as a general policy)
>   - makes gnu go a tiny little bit faster

Speed is not really an issue. Maintainability is and there it's
unclear whether this would be a win. I don't think it would be.

> there are of course some drawbacks:
>   - patterns are not so clear to a nonprogrammer, but this is not
>     too bad since nothing prevents one from writing patterns without
>     scripts

Anyone who considers writing new patterns needs to be able to read the
old ones.

> one point where dynamic valuation change may become a good strength
> boost is shape patterns. we know that they often match when shouldn't
> and make gnu go play stupid moves. when in certain positions it looks
> risky to eliminate negative shape value completely, we can at least
> lower it under some circumstances with a script.

It's not clear to me that there are any useful circumstances where
eliminating negative shape would be bad but reducing it would be good.

> in general, we should probably put some more effort in reducing the
> number of false pattern matching. for instance, i only came up with
> "lib(A)>2 && same_dragon(A,B) && worm_genus(C)==0" constraint after
> some pondering and i'm pretty certain there many patterns out there
> which lack similar constraints (i agree it is not ideal, but at least
> it is much better than nothing). it is quite difficult to make patterns
> general enough, yet match only in proper places, but it is definitely
> a worthy goal.

Proper constraints are very important, and difficult, yes.

> Paul
> 
> 
> --- patterns/endgame.db.orig  2003-03-11 02:07:34.000000000 +0200
> +++ patterns/endgame.db       2003-03-11 19:01:01.000000000 +0200
> @@ -737,6 +737,76 @@ Pattern EE414
>  :8,OXed,terri(3)
>  
>  
> +Pattern EE415
> +# pp New pattern (3.3.18)
> +
> +|*O?
> +|OXX
> +|.OX
> ++---
> +
> +:8,X,terri(0.1),reverse_followup(2)
> +
> +|*A?
> +|OXX
> +|.OX
> +----
> +
> +;alive(A)

This pattern is okay as a temporary solution but the proper solution
must be to fix the move valuation:

  Move at N11 defends M13 with bad ko
  Move at N11 strategically or tactically unsafe
  [...]
    N11: 0.0 - tactical move vs M13 (unsafe move)
  
so that N11 is no longer considered unsafe. Tracing backwards
(-d0x1000 is useful) we see

  owl_does_defend N11 M13(M13), result 0 (0, 0 nodes, -0.00 seconds)

which should really report defense with bad ko, just like the tactical
status.

> +Pattern EE416
> +# pp New pattern (3.3.18). See trevorc:1120.
> +
> +
> +|OX??
> +|.OO?            large to huge corner move
> +|..*X
> ++----
> +
> +:8,OXe,terri(script),reverse_followup(script)

With proper helpers we shouldn't need this "script" business.

> +
> +|DB??
> +|bCC?
> +|.a*A
> ++----
> +
> +; lib(A)>2 && same_dragon(A,B) && worm_genus(C)==0

I'm afraid this constraint is somewhat bogus. lib(A)>2 is often okay
but sometimes needlessly restrictive, consider

|.O....
|.O....
|OXXXX.
|.OOOXX
|...X.X
+------

same_dragon(A,B) isn't really relevant at all, although it has a
tendency to correlate with the situations where the pattern applies.

worm_genus(C)==0 is a necessary but absolutely not sufficient
condition. I would even go as far as to say that worm genus is such a
crude concept that we should aim to eliminate it from the engine
entirely. It was once useful in the very first incarnation of the life
and death code but today it is seldom what we really want.

> +> reverse_followup = 0;
> +> if (lib(D) == 2) {
> +>   terri = 4;
> +>   if (!xplay_defend(*,?,b,C))
> +>     reverse_followup = 2 * wormsize(C) + 1;
> +> }
> +> else
> +>   terri = (xplay_defend(*,a,b,C) ? 2 : 3);

I'd rather have a couple of similar patterns than needing to pars this
expression.

> +
> +Pattern EE416b
> +# pp New pattern (3.3.18). Same as EE416, but for the other color.
> +
> +|XO??
> +|.XX?            large to huge corner move
> +|..*O
> ++----
> +
> +:8,OXe,terri(script)
> +
> +|DB??
> +|bCC?
> +|.a*A
> ++----
> +
> +; lib(A)>2 && same_dragon(A,B) && worm_genus(C)==0
> +
> +# GNU Go finds followup value itself, so it is not specified here.

We should really try to make the engine as good at finding reverse
followup values as it is with ordinary followup values.

> +> terri = 4;
> +> if (lib(D) > 2)
> +>   terri = (oplay_defend(*,a,b,C) ? 2 : 3);

In the end, though, we rather should try to avoid the need to set
explicit territorial values at all. Looking at the valuation output we
have in trevorc:1120,

Move valuation:
    A3:   - A2 territory change 1.00 (0.00 -> 1.00)
    A3:   - A1 territory change 1.00 (0.00 -> 1.00)
  A3: 2.00 - change in territory
  A3:   0.00 - total followup value, added 0.00 as territorial followup

There should be a point for territory change at B1 too. This is a
false_eye_territory situation where the current code isn't good
enough. The proper solution to the territorial value problem here
would be to improve that code.

> -loadsgf games/trevor/auto/c78.sgf 100
> -1410 gg_genmove white
> -#? [J4]*
> +# J4 allows black to kill with G3 or H2 - removed test /pp
> +#loadsgf games/trevor/auto/c78.sgf 100
> +#1410 gg_genmove white
> +##? [J4]*

I think you have missed something. After white J4, black G3, white G5,
black gets the small change. More interesting is white J4, black H2,
white G5, black G6, white G3, black D2, white H5. Now black can play
G4 to create a huge ko but unfortunately doesn't have a single ko
threat.

Yes, this is a difficult position.

>  loadsgf games/trevor/auto/c78.sgf 102
> -1420 gg_genmove white 6
> +1420 gg_genmove white
>  #? [J4]

You may or may not know this, but the "6" is not accidental. It's used
to determine the random seed so that J4 is valued lower than G3 in
case they have the same nominal value (which they had when the test
was created).

On the other hand this feature isn't all that useful and has been
removed from the gtp standard command reg_genmove because it doesn't
make sense for engines in general.

/Gunnar