Re: [gnugo-devel] fast_defense() improvement

[Paul Pogonyshev]

nando wrote:
> The idea is simple : there might be some adjacent opponent stones in atari,
> checking if capturing them wouldn't give enough liberties to win, proved to
> be cheap enough.
> 
> No breakage. Performance impact :
> - reading nodes :      -4.7%
> - owl nodes :        < +0.1%
> - connection nodes : < +0.01%
>
> My imprecise timings give me a 4% speedup.

Looks very good.
 
> - new function count_adj_stones() in board.c

I would prefer count_adjacent_stones().

> +    /* We aren't interested in ko (at this stage). And playing
> +     * our own last liberty to capture is prone to snapbacks,
> +     * so better let the 'normal' reading routines do the job.
> +     */
> +    if ((liberties == 1 && liberty_of_string(lib, str)
> +      && countstones(adjs[j]) <= 2)
> +     || is_ko(lib, color, NULL))
> +      continue;

(libs[0] == lib) instead of liberty_of_string() seems better.  However,
I don't understand why this check is needed at all: if you run into
snapback, you only don't get enough liberties to reach `goal_liberties'
or am I missing something?

> +    /* Let's totalize liberties of the friendly strings around the 
> +     * lunch.
> +     */
> +    memset(mw, 0, sizeof(mw));
> +    adj2 = chainlinks(adjs[j], adjs2);
> +    for (k = 0; k < adj2; k++) {
> +      alib = findlib(adjs2[k], MAXLIBS, alibs);
> +      for (l = 0; l < alib; l++) {
> +     mw[alibs[l]]++;
> +     if (mw[alibs[l]] == 1)
> +       total++;
> +      }
> +    }
> +
> +    /* The captured string is treated as common liberties, and
> +     * some adjustements are made :
> +     * - we're adding a stone for capturing the lunch (-1)
> +     * - opponent might be able to remove a liberty (-1)
> +     * - and possibly force us to connect (-1)
> +     */
> +    total += countstones(adjs[j]) - 2;
> +    if (mw[lib] < 2)
> +      total--;
> +
> +    if (total >= goal_liberties) {
> +      *move = lib;
> +      return 1;
> +    }

This looks risky.  First of all, I cannot read this, at least quickly
enough.  And secondly, the attacker gives up when _the attacked_
string gains 5 (or 4) liberties, it doesn't consider adjacent strings
in this respect.  So you seem to introduce deviations from "normal"
`reading.c' logic here.  Maybe this also explains your snapback test
above, but then it seems like another reason to drop these
complications.

Can you verify if this part gives any serious improvement?  Maybe we
can live with the simpler things, counting only direct liberties?

Paul