Re: [gnugo-devel] Patch: Strategic effect for strategic attacks and defenses

[Arend Bayer]

Inge wrote:

> Here is a patch that I have wanted to do for a very long time.

I have wanted to do s.th. similar, too, for a very long time...good you
actually started it!

> The way it works after this patch is that the weakness value is
> recomputed after the move.  The change in weakness is multiplied with
> the effective size of the dragon to get the strategic bonus.
>
> Unfortunately, the weakness is not easy to compute after a move is
> made, because the weakness value is dependent of so many other
> factors, including owl status.  There is much to be improved here.
> However, the patch below can be thought of as a seed for further
> improvements.

> I ran the regressions on the changed gnugo and got 13 PASSES and 21
> FAILs.  However, then I discovered a bug and after I fixed that, some
> half of the FAILs had disappeared and a number of new PASSes had
> appeared.  I didn't have time to rerun it all, but that is the result
> I got when I reran a few tests manually (among them strategy and
> nngs1).

I've run regressions with your patch on current CVS, results are below.
(Btw, the patch didn't apply, I'll put a re-diff up at devel.html.)

I think it is a bit dangerous to blame other parts of the engine when
doing strategic effect tuning. Strategic effect comes last, after all
other parts in the engine have committed their sins and blunders, and
it should partly be considered a help to guess around such mistakes.

E.g.
> strategy:39   FAILs, but partly for other reasons
>               R6, which is the only move that is valued higher, has
>               move reason that it owl-attacks R6 and a territorial
>               value of 23.45, which is doubtful.  Also, P16, the
>               correct move lacks a few followup move reasons, like
>               the fact that it threatens to cut off and capture
>               Q13.
...,well, R6 has also followup values (if white does nothing, then Q3 will
shut white in in sente), and unless we reenable --owl-threats (or write
some --cut-threats), P16 will never get such a followup bonus.

After your patch, P16 does get a strategic bonus of 0.0. This is clearly
not what we want. Maybe it's the fault of the "-" sign commented on
below? (Would be nice if changing that would magically improve the
regression delta.)

> +static float
> +dragon_delta_safety(int dr, int pos, int color)
> +{
> +  int    dragon_safety = DRAGON2(dr).safety;
> +  char   saved_stones[BOARDMAX];
> +  float  weakness;
> +  float  delta_terri;
> +  float  followup_value;
> +  struct dragon_data  save_dragon_data;
> +  float  escape_route;
> +  float  retval;
> +  int    i;
> +
> +#if 0
> +  gprintf("dragon_delta_safety() for dragon %1m, %C move at %1m\n",
> +       dr, color, pos);
> +#endif
> +
> +  /* Kludge: If a dragon is dead, we return 1.0 in order not
> +   * to try to run away.
> +   */
> +  if (dragon_safety == DEAD
> +      || dragon_safety == INESSENTIAL
> +      || dragon_safety == TACTICALLY_DEAD)
> +    return 1.0;
This has to be 0.0 I think.
> +
> +  /* When scoring, we don't want to reinforce ALIVE dragons. */
> +  if (doing_scoring && dragon_safety == ALIVE)
> +    return 1.0;
Same here.
> +
> +  weakness = DRAGON2(dr).weakness;
> +  memset(saved_stones, 0, BOARDMAX);
> +  saved_stones[pos] = INFLUENCE_SAVED_STONE;
> +  delta_terri = influence_delta_territory(pos, color, saved_stones,
> +                                       &followup_value);

Unless I am mistaken, this does not do what it pretends to do. The call
influence_delta_territory() will just returned the cached value from
the previous call from estimate_territorial_value(). If this is the case,
then it is probably better to pass this value around inside value_moves.c
instead of relying on the caching (e.g. this would magically command that
estimate_territorial_value() has to be called before
estimate_strategical_value() ).

If I am mistaken, i.e. if move_influence is recomputed here, then this
would be a big performance problem.

I like the idea to simply take the territorial value as measure for the
likely change in moyo value. It might usually be a bit high, though.
OTOH it would not be too much work to re-compute the moyo value
properly.

> +  /* Add the move at 'pos' to the dragon if the move is the same
> +   * color as the dragon.  Otherwise find a neighboring dragon and
> +   * add to that one.
> +   *
> +   * FIXME: Do this for real later, but test it first.
> +   */
> +  save_dragon_data = dragon[pos];
> +  if (color == board[dr])
> +    dragon[pos] = dragon[dr];
> +  else {
> +    /* Find a neighbour dragon. */
> +    for (i = 0; i < 4; i++) {
> +      int  pos2 = pos + delta[i];
> +
> +      if (ON_BOARD1(pos2) && board[pos2] == color) {
> +     dragon[pos] = dragon[pos2];
> +     break;
> +      }
> +    }
> +    if (i == 4) {
> +      /* There was no neighbor.  Fake one.
> +       * FIXME: This is *real* ugly, but is necessary because
> +       *        influence_delta_moyo has an assertion for id != 0.
> +       */
> +      dragon[pos].id = number_of_dragons;
> +    }
> +  }
> +  escape_route = compute_escape(dr, 1);
> +  dragon[pos]  = save_dragon_data;

Now that is a matter of opinion, but I think the dragon[] array should
only be touched by dragon.c. More importantly I fear the compute_escape()
call (which triggers a recomputation of escape_influence) might be a
performance problem.


> +     /* Check how much the weakness of the dragon is affected by
> +      * the move and put a score on that.
>        */
> -     this_value = (dragon[aa].effective_size
> -                   * (1.0 - dragon_safety(aa, 1)));
> +     if (color == board[pos])
> +       this_value = (dragon_delta_safety(aa, pos, color)
> +                     * dragon[aa].effective_size);
> +     else
> +       this_value = -(dragon_delta_safety(aa, pos, color)
> +                      * dragon[aa].effective_size);

Are you sure the "-" sign is right here? Me thinks dragon_delta_safety
always returns a non-negative number.

Arend


14 PASS, 24 FAIL:
./regress.sh . trevora.tst
200 unexpected PASS!
220 unexpected PASS!
480 unexpected PASS!
./regress.sh . nngs1.tst
35 unexpected FAIL: Correct 'D13', got 'N8'
./regress.sh . strategy.tst
27 unexpected FAIL: Correct 'C3', got 'F2'
./regress.sh . rosebud.tst
1 unexpected FAIL: Correct 'E16', got 'C18'
./regress.sh . trevorb.tst
220 unexpected PASS!
390 unexpected FAIL: Correct 'G6', got 'F7'
450 unexpected FAIL: Correct '!L6', got 'L6'
830 unexpected FAIL: Correct '!H11', got 'H11'
./regress.sh . strategy2.tst
59 unexpected FAIL: Correct 'B1', got 'PASS'
64 unexpected FAIL: Correct 'B13|C13|C12|E14|D14', got 'P12'
70 unexpected FAIL: Correct 'M15|J15|N16|J16', got 'C15'
90 unexpected FAIL: Correct 'B14|D17', got 'H2'
./regress.sh . nicklas3.tst
401 unexpected FAIL: Correct 'A5', got 'C6'
./regress.sh . manyfaces.tst
1 unexpected PASS!
./regress.sh . trevor.tst
190 unexpected FAIL: Correct 'B7', got 'F5'
220 unexpected FAIL: Correct 'E8', got 'A7'
./regress.sh . nngs.tst
1670 unexpected PASS!
./regress.sh . trevorc.tst
350 unexpected PASS!
960 unexpected FAIL: Correct '!H6', got 'H6'
1650 unexpected PASS!
./regress.sh . strategy3.tst
101 unexpected FAIL: Correct 'M16', got 'M17'
./regress.sh . global.tst
25 unexpected PASS!
33 unexpected PASS!
./regress.sh . arend.tst
35 unexpected FAIL: Correct 'H17|J19', got 'R10'
./regress.sh . 13x13.tst
15 unexpected PASS!
87 unexpected PASS!
./regress.sh . trevord.tst
230 unexpected FAIL: Correct 'G6', got 'L9'
./regress.sh . strategy4.tst
216 unexpected FAIL: Correct '!B6', got 'B6'
./regress.sh . handtalk.tst
19 unexpected FAIL: Correct 'J8', got 'H10'
./regress.sh . nngs2.tst
480 unexpected PASS!
./regress.sh . nngs3.tst
400 unexpected FAIL: Correct 'N13', got 'Q15'
630 unexpected FAIL: Correct 'A17', got 'C16'
700 unexpected PASS!
800 unexpected FAIL: Correct 'G4', got 'E3'
./regress.sh . strategy5.tst
276 unexpected FAIL: Correct 'A18', got 'PASS'
./regress.sh . century2002.tst
120 unexpected FAIL: Correct 'L3', got 'P9'