gnugo-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gnugo-devel] Patch: Better valuation of attack threats


From: Gunnar Farneback
Subject: Re: [gnugo-devel] Patch: Better valuation of attack threats
Date: Mon, 14 Jan 2002 17:33:41 +0100
User-agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/20.7 (sparc-sun-solaris2.7) (with unibyte mode)

Inge wrote:
> Here is a patch that finally makes the valuation of strategy:17
> correct.  Or almost so, at any rate: There is still a small
> contribution from shape that doesn't really apply here.

There are things in this patch making me very nervous.

> +  color = OTHER_COLOR(board[ww]);
> +  if (!trymove(pos, color, "adjusted_worm_attack_threat_value", ww,
> +            NO_MOVE, NO_MOVE)) {
> +    gg_assert(0);

Are you sure we don't risk an assertion failure here if the move is an
illegal ko capture? I.e. are you sure that case can't happen?

> +  }
> +
> +  attack(ww, &aa);
> +  retval = adjusted_worm_attack_value(aa, ww);
> +  popgo();

Okay, so we call adjusted_worm_attack_value when stackp == 1. Let's
see what that function does:

| static float
| adjusted_worm_attack_value(int pos, int ww)
| {
|   int color;
|   int num_adj;
|   int adjs[MAXCHAIN];
|   int has_live_neighbor = 0;
|   float adjusted_value = 2 * worm[ww].effective_size;
|   float adjustment_up = 0.0;
|   float adjustment_down = 0.0;
|   int s;
| 
|   color = OTHER_COLOR(board[ww]);
|   num_adj = chainlinks(ww, adjs);
|   for (s = 0; s < num_adj; s++) {
|     int adj = adjs[s];
| 
|     if (dragon[adj].matcher_status != DEAD)
|       has_live_neighbor = 1;
| 
|     if (dragon[adj].matcher_status == DEAD
|         && 2*dragon[adj].effective_size > adjustment_up)
|       adjustment_up = 2*dragon[adj].effective_size;
| 
|     if (worm[adj].attack_codes[0] != 0
|         && !does_defend(pos, ww)
|         && 2*worm[adj].effective_size > adjustment_down)
|       adjustment_down = 2*worm[adj].effective_size;
|   }
| 
|   if (has_live_neighbor)
|     adjusted_value += adjustment_up;
|   adjusted_value -= adjustment_down;
| 
|   return adjusted_value;
| }

It's looking at both the dragon and the worm arrays, but those are not
generally valid when stackp > 0. It IS possible to use them, but it
requires much care. Here it seems to me that the trymove() may have
1. Introduced a new neighbor string of ww, which will be found by
   chainlinks().
2. Moved the origin of one the existing neighbors. This new origin
   will be returned by chainlinks().

In both those cases dragon[adj] and worm[adj] will contain invalid
data.

/Gunnar



reply via email to

[Prev in Thread] Current Thread [Next in Thread]