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

[Inge Wallin]

Arend wrote:

> 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.

I don't agree.  The original implementation worked this way, but I
think the goal for the new implementation should be accuracy rather
than glossing over mistakes in earlier phases.

And I don't think of it as blaming.  What the patch does is uncover
some previously hidden bugs that were invisible before.  

> 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.)

I will have to look at this.  It is very possible that you are right.

> > +    return 1.0;
> This has to be 0.0 I think.

> > +    return 1.0;
> Same here.

You are probably right.  That's cut & paste programming for you.

> > +  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() ).

I think you are wrong here.  The call from influence_delta_territory
is taken from similar examples in value_moves.c.  At least it looked
as if it was correct at those places.


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

Are you sure? I did a profile, and the run time for delta_territory
was very insignificant.


> 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.

I would think that the moyo would increase or decrease more than the
territory.   Why do you think that the territory will increase more? 

> 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.

Regarding dragon[], you might be right, but I wanted to have a
proof-of-concept quickly.  Thinking of it now, perhaps this function
really belongs in dragon.c  About performance, I think you are wrong
(see above). 


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

No.  At least, that is not what it is designed to do.  If we play near
an opponent dragon it should be weakened, i.e. the return value is
negative. 

          -Inge