Re: [gnugo-devel] endgame tuning

[Arend Bayer]

Paul wrote:
> Gunnar wrote:
> > 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.
> >
> > [and so on]
>
> oh well, everything went wrong. so i have explained my arguments in the
> original mail and if no one else shares my point of view, then we can
> simply bury the topic.

Let's not bury it too quickly. Of course, adding a new machinery (as your
"terri(script)" must come with an improvement, because it adds
complexity. (And changing elements of the pattern struct just in time
does look a little fragile, as you noted yourself. In fact, I wonder why
the pattern arrays aren't marked "const".)

> 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

As an aside, I now think this is pretty irrelevant. I doubt we will find
many people interested in tuning pattern databases without being able to
get the whole picture by reading the code.

> +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)
> +
> +
> +|DB??
> +|bCC?
> +|.a*A
> ++----
> +
> +; lib(A)>2 && same_dragon(A,B) && worm_genus(C)==0
> +
> +> 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 think both (script) values here work around a problem somewhere else.

The problem about terri() is probably that there is an O block at !. The
pattern producing that block should be identified and fixed. (This will
also solve similar cases where your pattern doesn't help, I suppose.)

As Gunnar pointed out, we should be able to work out the reverse
followup value of * automatically from the attack threats. As for now,
it might be best to add a "prevent_attack_threat(C)" helper that adds
the appropriate reverse followup value.

> +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.
> +> terri = 4;
> +> if (lib(D) > 2)
> +>   terri = (oplay_defend(*,a,b,C) ? 2 : 3);
> +

I think the distinction between 2 and 3 as value should be fixed in the
territory valuation similar to the problem above. (This is a vague
guess, I haven't looked at the problem.)
I presume you are right that we currently won't be able to find a
territory value of 4. Maybe this can be solved by improving Gunnar's
false eye code -- which would then indeed be a solution with non-static
knowledge.


So my conclusion would be that so far, the benefits are a little small
compared to the added complexity.  I might change my opinion if I see
bigger problems being solved with dynamic patterns, where our current
framework with "actions" isn't sufficient.

Arend