Re: [gnugo-devel] (no subject)

[Inge Wallin]

Gunnar wrote:
> > The cause of all this is that the information from atari_atari is not
> > used in the dragon analysis.  But this is a chicken and egg problem:
> > Atari_atari uses information about dragons and dragon statuses in
> > compute_aa_status() and the dragon analysis should use information
> > from atari_atari.
> 
> A connection reader should be able to see that there's no way to
> connect S5 and Q7. The amalgamation code may need help from a
> combination module too, but connection reading must be the corner
> stone in the future.

Indeed, but consider the following.

Suppose we have 4 worms, A, B, C and D.  A is connected to B, B to C
and so on.  On top of this D is connected to A so they form a ring.
Now, suppose that none of these connections can be broken by
themselves, but in the process of defending the connection between A
and D, C is captured.  This is in essence what is happening in the
example that I described.  

I don't think that this could be analyzed by the connection reader by
itself.  We also need information about the tactical status of the
worms involved.

> Splitting dragons after amalgamation is hopelessly complex. It may be
> a better idea to introduce a new type of unit between worm and dragon.

Or to make amalgamation temporary until the analysis is completed.
Maybe just form a struct of two pointers saying "these two worms are
connected and will probably belong to the same dragon".  I don't think
this is the answer we are looking for, but neither do I think that a
new type of unit is it.  

        -Inge