Re: [gnugo-devel] worms from try_move

[Gunnar Farneback]

Kevin wrote:
> A SUGGESTION: LUMP WORMS INSIDE THE SAME DRAGON FOR TRY_MOVES
> 
> Right now, the stones of the same dragon from non-try_moves and
> try_moves are treated as separate worms, even they are physically
> connected. I know there may be some reasons to keep it this way, but
> would it be practically useful if we can have a option (or something
> like that) to get them combined?

It's not entirely clear what you want, but my interpretation is that
you wish to have the worm data updated after each trymove() call. This
is out of the question because

a) The computation of worm data is fairly slow and trymove() is
   intended to be used when doing all kinds of reading, including
   tactical reading which has very limited use of most of the worm data.
   Talking actual numbers (from a profiling I did at some time) running
   make_worms() took 34 ms while 2.6 million trymove() calls were done
   per move, summing up to something like 24 hours extra per move.
b) The computation of worm data requires tactical reading and thus
   trymove() calls, leading to an infinite recursion.

So this is not even possible to do.

> For example, the non-try_move part has worm which is invincible, a
> stone from try_move which is physically connected to this invincible
> one should also invicible. Now, they are separated worms, so the
> attributes of the try_move worm indicate it is non-invicible.

If it's specifically the invincibility status you want to have
updated for each trymove(), this might be possible to do in some
approximate, conservative manner. This would then be included in the
low level string data in board.c rather than in the worm data. Still
there's the performance question and I'm rather doubtful that the
benefit of having up to date invincibility status would be large
enough to motivate the slowdown.

But maybe I misunderstood what you wanted.

/Gunnar