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

[Portela Fernand]

Arend wrote:

> Isn't the simplest explanation for this that most dragons (at least
> those where you still get a lot of matches) occuring in games are alive?

Most probably. And I 100% agree that the optics code needs improvements. 

> What I think would be useful here is a "fast_disconnect()" that would be
> the same as disconnect(), except with very low depth and node limits.
> (And in doubt we can just assume that the stone is not yet connected,
> and maybe amalgamate it later.

I made a funny experiment once: force defense to consider the stone out of
the goal if it's not directly connected. As you can imagine, performance...
Also, it made GG slow (series of jumps/connections while defending) and
yielded a lot of FAILs.

I like you idea though. Maybe I'll give it a try later.

> I had hoped for that, but didn't achieve much. The net effect was
> certainly almost zero. Anyway, I think the better way to solve this is
> to make the owl code aware that a dragon is obviously unkillable
> (because if a dragon becomes obviously unkillable during the owl
> reading, we shouldn't waste owl nodes there either).
> 
> I'd still be interested to hear about the changes you wanted to propose.

Oh, they were very simple and based on statistics I collected. In the old
code, there were a couple tests like "escape_route > 25" for instance, in
which case GG wouldn't use the owl code. My stats showed that some other
conditions like "escape_route > 20 && moyo_size > 0" would always (in
the regressions) lead to a 0 result with certainty for an attempted
owl_attack() 

Nothing that can be used now I think. I can re-run stats collecting and see
if there's possibly an improvement to make in comparison with the current
settings you defined.

> I'll add:
> 6. Big dragons that have many places where owl defense patterns can
> match will never be considered dead.
>
> That is because when there are many patterns matching, the reading will
> always go below OWL_DEPTH, and then the dragon is considered alive. This
> is an important thing to fix, I believe.

Indeed. I have yet no idea how though.

> > Breakage (compared to CVS before arend_3_13.7a) is rather light :
> >  9 PASSes and 2 FAILures.
> 
> The breakage looks obviously good. Did you measure the performance
> impact if you leave out the change to D1356?

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 ?

> 1) Seriously improve eye space analysis.
> 2a) Better generation of escape moves. (This includes moves connecting
> to another dragon. Of course same goes for attacking moves preventing
> escape.)
> 2b) Bettter analyis of escape value.
> 3) Better recognize weaknesses in the surrounding chains.
> 4) Recognize cuts in the dragon.
> 5) A better move ordering that uses more input than just hard-coded
> pattern values.
> (...)
> I think Gunnar and Paul have ideas for 1). Once I've finished my big
> influence cleanup, I want to make a serious try at 2b).

Hmm, it seems we all agree about where to look at without needing to talk
much about it :)

I'm currently toying around 2b and 5. For 2b, I'm trying to reduce escape
values for goal's own moyo with the hope that escape overestimation will be
corrected for one, and that it will make it less attractive to escape in its
own territory (less sure about the latter though). For 5., I'm trying some
simplistic schemes based on escape measures, something like prioritize moves
which reduce escape potential over other moves.

Nothing very substantial yet, but interesting, about neutral regressions
breakage and good owl nodes improvements (5~10% decrease)

In order for me to decide whether to stop on this work or not, I'd like to
know what you plan to do with 2b. If my approach is clearly inferior, then
no need for me to waste too much time with it.

> It also seems to me that escape moves might better be generated
> systematically than via patterns. S.th. as "jump towards biggest source of
> escape value of the dragon". Well that may work, or it may not. But I do
> think it's more flexible.

I thought once about such a thing, but didn't manage to figure a good way
to implement it.

But this reminds me a funny experience I made once. I called it the "cosmic"
player. Principle was simple : generate moves at the boundaries of
neighboring moyos. I ran a twogtp match (100 games) and gave up on it
after seeing no perceptible strength increase. In that attempt, I didn't
remove the moyo expanding (only) patterns from the databases, so moves
proposed by this generator weren't chosen very often anyway. This may
account for the not perceptible difference. Maybe I should retry with
patterns removal...

> Probably 3) is hard. 4) is hard to do without badly hurting performance.

Agreed.

> As for 5), I think it would make a lot of sense to try iterative
> deepening in the owl code. This means doing the same reading repeatedly
> with increasing reading depth, until we have reached full depth. The
> previous results then get used to select the move ordering.

Looks tough to implement. Have fun ! :)

/nando