gnugo-devel
[Top][All Lists]
Advanced

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

Re: [gnugo-devel] liberty counting, revised


From: Paul Pogonyshev
Subject: Re: [gnugo-devel] liberty counting, revised
Date: Fri, 18 Oct 2002 23:00:22 +0300

Trevor wrote:
> However, this entire patch does make me a little uneasy.  Did you leave
> the assertions in place in the patch?  Did you add an assertion for the
> revision to fastlib also?

i deleted the assertion after i checked the new code. i had to do it
because it went this way:

result1 = [new code];
result2 = [old code, using trymove];
assert (result1 == result2);

it became meaningless after removing the old code. besides, it forced
me to comment out all early returns (reached maxlib liberties) and i
wanted them back.

as to fastlib, i didn't check it. however, i think it can be done by
just pondering the intension of those conditions. here is how i can
explain the new ones:

      if (neighbor_size == 1
         || (neighbor_size == 2 && !ally1)) {

if neighbor_size is 1, we receive exactly one liberty in the vertex
where the stone is captured. in no way it can be counted twice, for it
bounds with (pos) only from one side and we never consider captures
outside that loop (neither in LIBERTY() macro nor in
count_common_libs()).

if neighbor_size is 2, then it bounds (pos) only from one side as
well. if we have no allies, then the captured neighbor gives only one
liberty (otherwise, the second stone of the neighbor can be adjacent
to one of the allies).

i wrote:
> i checked the speed. rewritten function is 4-8 times faster (depending
> on position) than the old one, which seems to be good enough ;)

this is true only when fastlib() fails, of course (for instance, when
libs != NULL or we have a considerable capture).

Paul





reply via email to

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