[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [gnugo-devel] Patch: Strategic effect for strategic attacks and defe
From: |
Gunnar Farneback |
Subject: |
Re: [gnugo-devel] Patch: Strategic effect for strategic attacks and defenses |
Date: |
Mon, 14 Oct 2002 23:00:54 +0200 |
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) |
Arend wrote:
> > + 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().
Yes, the caching in influence_delta_territory() does not go together
with this code.
> 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
I'm not sure I follow the reasoning here but the main purpose of the
caching in influence.c is to reuse results if value_moves() is called
a second time after searching endgame.db.
> (e.g. this would magically command that estimate_territorial_value()
> has to be called before estimate_strategical_value() ).
This is already the case and documented:
| /* Estimate the value of various aspects of the move. The order
| * is significant. Territorial value must be computed before
| * strategical value. See connection_value().
| */
| estimate_territorial_value(pos, color, score);
| estimate_strategical_value(pos, color, score);
/Gunnar
Re: [gnugo-devel] Patch: Strategic effect for strategic attacks and defenses, Arend Bayer, 2002/10/14
Re: [gnugo-devel] Patch: Strategic effect for strategic attacks and defenses, Gunnar Farneback, 2002/10/19