Re: [gnugo-devel] influence and more

[Inge Wallin]

> 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.

This sounds like a very good thing.  I have wanted to improve my
strategic bonus patch for a long time now, but reoccurring batches of
heavy work keeps interfering.  If you go through with this, my job
would become easier, I think.  

> 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.)

I agree about this.  We might, however, want to use non-linear
relation between .weakness and need to enforce the dragon,  The
sigmoid function is standard in such cases.

> 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.)

Much code duplication can be avoided if you provide good helper
functions that can be called to set up things.


> 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.

Some of these things might take a lot of time.  Do you think you could
investigate the possibility to make them incremental like deep down in
the board code?

    -Inge