gnugo-devel
[Top][All Lists]
Advanced

[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




reply via email to

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