RE: owl improvements (Re: [gnugo-devel] Owl tuning)

[Portela Fernand]

Dan wrote:

> I should say accept that Nando's methodology leading to the
> removal of these patterns is interesting and valid. But, I would
> argue, let's go slowly for the reasons I listed in my previous
> e-mail.

Statistics are dangerous. There is a (very) large number of factors which
can lead to misinterpretations and/or misuses. It took me a quite long time
to find a correct/valid way to collect the data in the first place, and I'm
now reasonably confident about these numbers. But I'm still unsure about
how to use them properly, and I'm just making various experiments in order
to find out.

I'm aware that regressions are _not_ a representative set of the Go game.
Which means that I totally agree that I (we) should be careful about using
these statistics to decide of changes.

I'm trying to find ways to make owl attacking more efficient. My work on
A1120 taught me that it's sometimes easier to simply remove a pattern and
see what happens, rather than to try to correct its behavior (by tuning a
bit the constraint for instance). A good example in this patch is A1107c.
While I agree with you Dan about the general usefulness of such moves, I
must say that the only case found in the regressions where this move is
effective is the resulting proposed A1504 pattern, which is actually too
specific. A better solution could be adding to A1107c a clause like : "the
move must actively threaten something (an eye for instance) at the same
time". But I don't think we can code this kind of helper as of now.

One thing is clear in my mind: the patterns for which I proposed a removal
need to be (at least) a lot more constrained. For instance with A107, it
seems to me that hoping to kill in following position might prove very
difficult if O is lacking external support

....X
X.*.X
....X
.....
-----

But GG is currently gonna try it whether it has support or not, because it
will probably find that the * stone is not tactically killable.

About A1609, I proposed its removal because of the performance and because
of its 'nature'. That is, it seems to me that such (obviously good) moves
should be found by the optics code in the first place.

In any case, thank you all for the comments and for spending some time on
this topic.

/nando