[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gnugo-devel] (no subject)

From: Inge Wallin
Subject: Re: [gnugo-devel] (no subject)
Date: Thu, 29 Nov 2001 12:49:46 +0100 (MET)

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.  


reply via email to

[Prev in Thread] Current Thread [Next in Thread]