Re: [gnugo-devel] OWL tuning: blocking escape with a knight's move

[Gunnar Farnebäck]

Martin Holters wrote:
> I arend2:10, after two steps of reading (b G3 w F4), the situation looks
> like this:
>
> 6|...O....
> 5|..O.X...
> 4|...X.O..
> 3|..OX.OX.
> 2|..OOXX..
> 1|........
>  +-------.
>   ABCDEFGH
>
> Here, gnugo misses the nice move at H5, capturing the two white stones,
> rejecting G3 in the first place. (G5 instead of H5 does not work, as
> then white can force his way out with a series of ataris after w G4 b
> H4, starting at H3.)

Agreed.

> The patch below solves this, adding a suitable attack pattern.

Nice, it's a very useful technique.

> However, it breaks strategy5:225 and ninestones:40. In the latter,
> the semeai reading looks bogus with and without the patch and I have
> not really figured out why the patch results in preferring D2 over
> C3.

I agree about ninestones:40. D2 is extremely ugly but C2 just isn't
working either.

> In strategy5:225, the now proposed move L11 matches exactly the pattern
> and indeed looks quite interesting, but IMHO does not work in this
> situation (some better Go player please confirm), but gnugo misses the
> correct defense in the reading process. If time allows, I will
> investigate this further and might add a suitable defense pattern in the
> coming days.

I'm not sure I'm strong enough to tell either but to me it looks like
L11 doesn't quite work as an owl attack. On the other hand it looks
perfectly playable, strengthening the position while white runs away.

> /Martin
>
> diff --git a/patterns/owl_attackpats.db b/patterns/owl_attackpats.db
> index ee75579..3db44e3 100644
> --- a/patterns/owl_attackpats.db
> +++ b/patterns/owl_attackpats.db
> @@ -1853,6 +1853,26 @@ X.O
>  :/,n,value(90)
>
>
> +Pattern A426
> +# See e.g. arend2:10
> +
> +?..?
> +*..O
> +..Y?
> +.O??
> +
> +:8,-,value(80)
> +
> +?ab?
> +*..O
> +CDe?
> +fG??
> +
> +; lib(G) == 3 && lib(e) > 2 && xplay_defend(D,C,f,G)

Maybe oplay_defend(*,D,C,f,G) instead?

> +; && (owl_escape_value(a) > 0 || owl_escape_value(b) > 0
> +;     || owl_escape_value(C) > 0)

These should be somewhat better to have before the reading part of the
constraint, to save time.

/Gunnar