[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [gnugo-devel] worms from try_move
From: |
Gunnar Farneback |
Subject: |
Re: [gnugo-devel] worms from try_move |
Date: |
Fri, 21 Mar 2003 19:37:58 +0100 |
User-agent: |
EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/20.7 (sparc-sun-solaris2.7) (with unibyte mode) |
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
- [gnugo-devel] worms from try_move, kevin yong, 2003/03/21
- Re: [gnugo-devel] worms from try_move,
Gunnar Farneback <=
- Re: [gnugo-devel] worms from try_move, kevin yong, 2003/03/21
- Re: [gnugo-devel] worms from try_move, Arend Bayer, 2003/03/23
- [gnugo-devel] 2 little things, max-d, 2003/03/23
- Re: [gnugo-devel] 2 little things, Arend Bayer, 2003/03/23
- Re: [gnugo-devel] 2 little things, max-d, 2003/03/23
- Re: [gnugo-devel] 2 little things, Arend Bayer, 2003/03/23
- Re: [gnugo-devel] 2 little things, max-d, 2003/03/23
- Re: [gnugo-devel] worms from try_move, Gunnar Farneback, 2003/03/23
[gnugo-devel] do some work for gnugo, kevin yong, 2003/03/25