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

[Gunnar Farneback]

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

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

The solution I would suggest is to rewrite atari_atari from scratch
with a pattern driven move generation (which looks for ataris and
other significant threats). After the first threat it should also try
to eliminate unrelated threats from consideration.

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

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 have only seen one regression difference:  Test 215 in owl.tst now
> PASSes. 

And what would this have to do with your patch? The owl code depends
neither on the atari_atari code, nor on the move valuation code. Also
the PASS of owl:215 was already reported in
http://mail.gnu.org/pipermail/gnugo-devel/2001-October/000287.html

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.

/Gunnar