gnugo-devel
[Top][All Lists]
Advanced

[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






reply via email to

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