Re: [gnugo-devel] strategic effect

[Arend Bayer]

Thx for your explanations, Gunnar; I'll just add some random remarks.

> > 3. Sometimes a move should get a strategic bonus and does not, and so
> > an inferior alternative that (correctly) gets the strategic bonus is
> > preferred. Happens with combination attacks (strategy:17);
> 
> Is strategy:17 the intended example? It looks more like an example of
> the first problem.
Oops yes indeed. Yet, even with my patch, N11 is still evaluated
incorrectly; it seems to me that capturing O10 doesn't get the bonus of
rescueing O9.


> > 4. There remain a few where the strategic bonus is simply too high.
> > (Maybe strategy:1,strategy2:65, viking:2). Capping the size of the
> > strategic effect might help here. OTOH, after seeing these results
> > in detail I do no longer believe that this capping is very
> > important;
> 
> If we cap I'd like a soft capping, so that a bigger dragon is still
> valued higher than a smaller one. A simple example would be the
> mapping
>        
> x -> a*x/(a+x)
> 
> where x is the dragon size and a is the asymptotic value for large
> sizes. 
Agreed.

> > Unexpected PASSes:
> > ego:4 PASSED -- difficult to solve this one
> 
> This is of the variety where saving a critical dragon isn't worth it
> because neighboring positions are seriously weakened by the fight (and
> the opponent is generally strengthened). It would be nice if we could
> give a negative strategical value in such cases. The difficulty is of
> course to come up with some robust heuristics to detect the situation.
> I have no good ideas here.
I assume this belongs to the situation where only a global evaluation of
a reading result would help. I really do not see a heuristic that would
help here.

> As a general rule we shouldn't try to work around mistakes that can be
> attributed to weaknesses in the connection analysis. Although there
> has been no visible progress for readconnect.c recently, dynamic
> connection analysis is high enough on the agenda that we should assume
> it to become reality in some form or another in the near future.
I am sure that GNU Go will improve a lot once readconnect works reliably.
OTOH I wonder a bit whether it is really useful to have the reading
analysis split up into one more module. How do you imagine the interaction
between the owl and the readconnect codes? After all, it is rather the
rule than an exception these two issues are interdependent. (Make an eye
by first threatening to cut s.th. off, connect by threatening to capture
cutting stones, make live with invasion stones by various attempts to
connect to the outside, reduce eye space while threatening to cut, etc. etc.)

-Arend