[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [gnugo-devel] OWL tuning: blocking escape with a knight's move
From: |
Martin Holters |
Subject: |
Re: [gnugo-devel] OWL tuning: blocking escape with a knight's move |
Date: |
Sat, 20 Mar 2010 11:05:58 +0100 |
Am Freitag, den 19.03.2010, 22:38 +0100 schrieb 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.
Maybe we should revise the regression test accordingly, also forbidding
C2?
> > 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.
>
Yes, strategically L11 might be ok, but the OWL reading is definitely
not convincing here.
> > /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
Agreed, I will revise the constraints accordingly.
/Martin