Re: [gnugo-devel] Patch: New move generator

[Inge Wallin]

I think that we are getting to the core of the matter

Gunnar wrote:
> Dan wrote in another message:
> > In a separate matter the moves at P5 and F6 are
> > misevaluated as being worth some 62 and 54
> > points. That's a separate matter. The issue is whether
> > the point at N11 is found and evaluated correctly. It
> > isn't necessarily the best point on the board, so
> > as a regression the test is imperfect, but it's a very
> > good example.
> 
> The problem with P5 and F6 is that the (huge) J14 dragon incorrectly
> is classified as WEAKLY_ALIVE instead of STRONGLY_ALIVE. This in turn
> is because the surrounding moyo size is evaluated to 0 instead of
> something very large, which of course is a bug. 

That is not the only problem.  The problem is also that the points for
strategic effect are awarded for the size of the dragon, not the
effect upon the dragon.

> When I count it carefully I get 21 points.

That sounds right to me.  

> Ah, now I see what I had missed in the patch. I only noticed the call
> to attacked_worm_value() from the valuation of ATTACK_MOVE and its ko
> relatives. I didn't see that that it was also called from
> ATTACK_EITHER and DEFEND_BOTH. There it makes sense to take effect on
> neighbors into account.

Aha!  I did think it was strange that you objected so to code that was
almost just moved from another place.

> (As a side note the valuation of ATTACK_EITHER and DEFEND_BOTH is a
> complete mess. I don't think it's possible to do this well without
> actually playing out the local position.)

True, but we are wading in approximations everywhere.

> The modifications to the ATTACK_EITHER and DEFEND_BOTH valuations are
> okay. The modification to ATTACK_MOVE does not make sense and is not
> acceptable. The name attacked_worm_value() is misleading since it's
> only useful in ATTACK_EITHER and DEFEND_BOTH. 

I think the general approach is sound, but I will look at it some more
to see what can be done to make it better.

> Further I have some
> comments about the code:

As you have already seen, it was snarfed from the valuation of
ATTACK_THREAT_MOVE.  It wasn't fully adapted since I try to release
early and then later fix errors.  That way I also give other people
the possibility to see the ideas and to make their contributions.

> >   int adjusted_value = 2 * worm[ww].effective_size;
> 
> Obviously adjusted_value should also be a float.

Definitely
> >     if (dragon[adj].color == color
> >       && attack(adj, NULL)
> 
> Why not look this up in the worm data?

As I said above, this code was just copied from the valuation of
ATTACK_THREAT_MOVE.  You have to ask yourself that since you wrote it
originally.  :-)

> I've checked four of these (not the ones in global) and they are all
> due to the bugs I pointed out above. As it happens the change to the
> ATTACK_MOVE valuation is not very effective since in most cases it's
> overruled by the OWL_ATTACK_MOVE valuation. This is not the case when
> level is less than six because
> find_more_owl_attack_and_defense_moves() isn't run then. It would be
> interesting to compare the performance with and without Inge's patch
> at level 5. I think the differences are likely to be more dramatic
> then.

I didn't think about that, but it would indeed be interesting.

> Inge wrote in the original comments to the patch:
> > I have started to worki on the move valuation to make that more
> > accurate.  The first step is to be more precis in valuation of
> > attacked worms.  Not only the worm itself, but also our own worms and
> > dragons saved by attacking the worm are now included in the
> > valuation.  I will carry the same ideas to defended worms and to
> > attacked/defended dragons.
> 
> You're welcome to try this but I'll promise that doing it for dragons
> will break things horribly.

I was mainly thinking of worms, but why would it break things horribly?

        -Inge