[gnugo-devel] influence and more

[Arend Bayer]

I have considered reorganizing the influence code for a while now, and
by now I have some very concrete plans, affecting the interface to the
influence code, but also the dragon safety computation and possibly
other stuff. I would like to invite comments.

1. I'd like to get rid of the distinction in influence.c according to
"territorial_influence". This will require reevaluating the long "if"
clauses in dragon.c that decide (based on pre-owl influence)
(a) whether a dragon shoould be owl analyzed
(b) its safety.
As I am somewhat skeptical about how tunable such if-constructs are, I'd
suggest to

2. use compute_dragon_weakness() already pre-owl for this decision.
As far as I am concerned, the safety values
WEAK, WEAKLY_ALIVE, ALIVE, and STRONGLY_ALIVE could be all be treated
as ALIVE, and if we need to make a decision based on the weakness of
a dragon, we use the continuos .weakness instead. (INESSENTIAL,
TACTICALLY_DEAD and INVINCIBLE should stay, as they do contain
important additional information that .weakness cannot provide.)

3. I think the interface to influence.c should be reorganized. The calling
function should
- set up the board[] state (with trymove() if necessary)
- pass an array telling which of these stones should be treated as alive
- pass an array of strengths, and
- and tell in which struct influence_data the results should be stored.

(This is for the current compute_initial_influence() and
compute_move_influence(). compute_escape_influence() will remain a bit
special.)

I.e. the long if-statements starting in influence.c:410 (headed by
"FIXME: Simplify the code below") should be moved to the calling
function in dragon.c/value_moves.c/aftermath.c, where the code will be
simpler. (This is at the cost of some code duplication, but not much
actually I expect.)

In addition to making influence.c more robust as a separate module. It
shouldn't be influence.c's business to interpret dragon-safeties.

But my main motivation is that this should easily allow more flexibility
in using influence.c, e.g.:
(a) We could use it to better determine the effective size of a dragon
by comparing territory with the dragon alive to territory with the
dragon marked dead.
(b) We could for example base joseki choices on comparing territorial
evaluation for the respective end positions. For example, I would
expect the influence code to make sane decisions about which side to
block after a 3-3 invasion under a 4-4 stone -- if we would only ask
it about its opinion.
(c) Of course this could be used for other special cases of look-ahead.

I actually think that (a) could help the "strategic defense"-tuning a
lot. Dan remarked that in most cases where he observed GNU Go neglecting
defense of a dragon during the opening, the effective size was actually
rather small (typically around 10.0). The influence code should
realistically give bigger estimates in these cases.

Arend