Re: [gnugo-devel] new vital attack pattern

[Paul Pogonyshev]

Martin wrote:
> > The very low value looks artificial, since the move is very logical.
> > I assume that you used so low value, because of positions like this,
> > where the move doesn't work as intended:
>
> No, admittedly, choosing a proper value is a black art to me. I just
> lowered the value and realised that this reduced the node counts in the
> regression suite while it still fixed the two tests I was aiming at. So
> I left it in place.

There are no strict rules about choosing values.  Just keep in mind that
moves from patterns valued higher get precedence.  Moves that tend to be
good in most positions are valued about 60--75.  Really important ones are
higher.  Moves that tend not to work always are about 40--50.  Good ko
moves are usually 45, while bad ko -- 35.  Lower values indicate problematic
patterns that should be tried only if there is really nothing else to do.

> > Regarding pattern constraint: seems good, apart from
> > `owl_maxeye(*)==1' part, which is too restrictive.  Consider e.g. this
> > position:
>
> [...]
>
> Dropping that constraint altogether substantially increases the node
> counts and moreover, produces more new failures than successes in the
> regression tests. I couldn't pinpoint why some tests broke, but it
> looked like GnuGO was dropping back to the exact same (wrong) moves it
> made in the games on which the tests were based. So my _guess_ is that
> this pattern without the maxeye-constraint matches too often and
> prevents the correct moves from being tried.

Maybe you should use `owl_maxeye(*) >= 1' or `owl_mineye(*) >= 1' or
`owl_proper_eye(*)'.  It would mean to play only in actual eyespaces.
Most likely, the expenses you faced after dropping this part of
constraint were caused by playing outside any eye, though i'm not really
sure.

To check constraint effects in reasonable time, you can make a short batch
of tests with only those tests which unexpectedly fail without
`owl_maxeye(*) == 1' (`regression/breakage2tst.py' should help).  Then
test different constraints only on that specific set of tests.

> > And two little bits regarding decorations.  It is a common practice to
> > add short "change log" in pattern comments (in this case, just a
> > mention of who and when created the file, see e.g. VA53).
>
> Ok, err... Should the version indicate the version I'm basing the patch
> or the one I hope it to be included in (i.e. 3.5.3 or 3.5.4)?

It should be the version for which the patch is intended (3.5.4 currently).

Paul