gnugo-devel
[Top][All Lists]
Advanced

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

Re: [gnugo-devel] endgame tuning


From: Paul Pogonyshev
Subject: Re: [gnugo-devel] endgame tuning
Date: Thu, 13 Mar 2003 00:04:20 +0200
User-agent: KMail/1.4.3

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.

> > +Pattern EE415
> > ...
>
> 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.

ok, this seems to be the only part of the patch which can go into cvs
(with a "temporary workaround" mark on it).

> > +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
> +------

agreed. i knew about this position, but i wanted to have precise/close
to precise move valuations and decided to leave this out of the pattern
and have it in another one (since it is yet another case and the fact
that 4-1 stone is alone and it has a false eye beside it is important)
someday.

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

it was a workaround for a missing helper.

> 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.

same as above.

> > -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.

agreed, i missed this.

Paul




reply via email to

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