[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [gnugo-devel] endgame tuning
From: |
Arend Bayer |
Subject: |
Re: [gnugo-devel] endgame tuning |
Date: |
Mon, 17 Mar 2003 10:12:14 +0100 (CET) |
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
- Re: [gnugo-devel] endgame tuning, (continued)
- Re: [gnugo-devel] endgame tuning, Gunnar Farneback, 2003/03/12
- Re: [gnugo-devel] endgame tuning, bump, 2003/03/12
- Re: [gnugo-devel] endgame tuning, Gunnar Farneback, 2003/03/12
- Re: [gnugo-devel] endgame tuning, bump, 2003/03/12
- Re: [gnugo-devel] endgame tuning, Gunnar Farneback, 2003/03/12
- Re: [gnugo-devel] endgame tuning, bump, 2003/03/12
- Re: [gnugo-devel] endgame tuning, Gunnar Farneback, 2003/03/12
- Re: [gnugo-devel] endgame tuning, bump, 2003/03/13
- Re: [gnugo-devel] endgame tuning, Heikki Levanto, 2003/03/13
Re: [gnugo-devel] endgame tuning, Paul Pogonyshev, 2003/03/12
- Re: [gnugo-devel] endgame tuning,
Arend Bayer <=
Re: [gnugo-devel] endgame tuning, Arend Bayer, 2003/03/22