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

[Inge Wallin]

Gunnar wrote:
> Inge wrote:
> > It contains a new move generator, which will be a generalized version
> > of atari_atari.  It is called combinations() and is contained in the
> > new file combinations.c (attached to this mail).  Currently it
> > contains calls to a module that finds multiple attack threats. More
> > will come here.
> 
> This is absolutely something that's needed. I don't know your design
> plans for this module but I would suggest to make it pattern driven.

I didn't plan to make it pattern driven at this point, but I agree
with you that it would be better.

> > I also plan to move much of atari_atari here and to generalize it to
> > try more threats than just simple ataris at low depths.
> 
> This is also needed. I've been planning to propose a rewrite of the
> atari_atari module for some time now. This module already does some
> very important work but it also has some serious shortcomings:
> 
> * It only knows about simple ataris. Clearly there are other
>   important moves too.
> 
> * There are attempts to increase the power of the atari_atari module
>   by the patterns CD103 and CD103a but this is too limited since that
>   pattern assistance only applies at the first move and there are
>   complications arising with the pattern matching since this leads to
>   a recursive call to matchpat(), which barely works.

My idea was to try all threat points instead.  That seems more general
and less wasteful of moves than CD103 to me.

> * The module has no concept of which ataris relate in a combination.
>   Although there's a trick to eliminate irrelevant ataris at the start
>   of the combination before reporting back the result, much effort is
>   spent on examining pointless combinations.
> 
> * It only proposes a single defense against combination attacks. This
>   sometimes leads to suboptimal moves being generated. A good example
>   is test case strategy3:101.

To sum it up, it seems that you have given it more thought than I
have.  My humble goal was just to make a better start on the first few
moves.  I think your goals are better, but I will continue to work on
mine since they are much simpler and easier to implement.

> > 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.
> 
> This approach I don't believe in at all. If the move also saves one of
> our worms it already should have a move reason for this and you would
> get a double valuation with this patch. Please show me one example
> where this patch improves the valuation.

I don't agree with you.  If your reasoning was correct, then
estimate_strategical_value() wouldn't be needed at all. Currently,
estimate_territorial_value() gives a value to capturing the worm or
dragon itself.  Then, later, estimate_strategical_value() looks at the
effects of this capture and sees what groups are defended or attacked
by the effect that the worm/dragon disappears.

Your new approach here above is of course also feasible, but in that
case we would have to rewrite a significant part of the move valuation.

And btw, the example I was using is incident 165 in strategy.tst (test
17). After the pass, i think it still underevaluates one branch of the
effects of N11, but it is much better. It still doesn't pass the test,
but that is due to the erroneous calculation of strategic effect,
which I also intend to attack soon.

> The main problem with the evaluation of attack moves is that the
> effective_size measure is too inaccurate. This may be possible to
> solve by modifying the interaction with the influence code, which I
> intend to attempt shortly.

I would be interested in hearing your ideas here.

> Btw I hope you're running "make all_batches" when you try to evaluate
> changes to the move valuation. Just running the first batch isn't very
> indicative.

Usually, I do, but yesterday it was late when I sent in the patch and
i wanted to go to bed.  I just convinced myself that the patch didn't
destroy anything.

> /Gunnar
> 
> _______________________________________________
> gnugo-devel mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gnugo-devel
>