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

[bump]

Nando wrote:

> No, and we should maybe postpone this patch until I make some more tests and
> measures. Specially since I don't see the lazarus:6 pass anymore (but I
> don't know yet if it comes from a conflict with another patch in the CVS or
> from some other tunings I just made). Has anybody else tested my patch ?

I have some reservations about patterns that are taken down in this patch.
Clearly we should be willing to take down patterns that cause bad moves
or to make them more specific. Also clearly there are some fundamental
problems with the owl code that will be very difficult to fix, and it
may be necessary to make some choices about whether a pattern does
more harm than good. 

When a pattern can have bad effects there are two approaches: first,
to take out the pattern, or reduce its value, or make it more
specific; second, in specific cases where GNU Go thinks a move works
but when it actually has a refutation, to add a refuting pattern.  The
second approach is more correct but can lead to big move trees and
running out of nodes.

Here are some specific patterns that Nando removes that I have
questions about.

A107: clearly there are times when a second line block is the best
move to attack. It seems likely when this pattern occurs that either
the dragon is alive, or this should be considered among the top
attacking moves. It would be a mistake not to consider it.

A207d: this pattern might contribute the correct move but sometimes
one space above or one space to the left is correct. It is bad shape.

A616: This pattern might be a candidate for being made more
specific. Since 2 successes are found in 268 regressions, 
those should be examined.

A1107c: patterns to defend the surrounding chain are important.
They need to be paired with D patterns which attack the chain.

A1402: Clearly a bad pattern since the corner is hard to kill
here.

A1609: This looks like clearly a good pattern to me, unless it
is redundant for some reason. Possibly too specific.

I'd be inclined to use the patch first taking out A1402 only. I
will run the regressions and report the effect of this.

> Also, I think we should maybe rethink the attacking scheme globally.
> When I take some simple references, like in following :
> http://senseis.xmp.net/?ApproachingALifeAndDeathProblemTheRightWay
> it seems to me that we shouldn't generate any kind of placements /
> vital moves, as long as there still is an escape route available.
> Easier said than done, but I think we could try to work in this
> direction.

and:

> As said above, too many moves are tried before the dragon has been
> properly confined. Any suggestions here to make a better job at this ?
> Maybe differentiate WINs by escape from others, and stop trying vital
> attack moves as soon as one of them failed because the goal escaped...

Yes, we've all seen GNU Go make placements against a group that can
escape easily. That's always a wasted move. Even if GNU figures out
that the placement doesn't work, it's a waste of nodes.

Here is something we could try immediately. Generally E patterns in
owl_defendpats.db are escape attempts, and s patterns in
owl_attackpats.db are placement (oki). So the rule would be never to
play an s attack pattern immediately after the opponent played an E
defense pattern.

Dan