Re: [gnugo-devel] liberty counting

[Gunnar Farneback]

Paul wrote:
>   - accurate_approxlib() is rewritten, moved to board.c and renamed to
>     exactlib() (since it is complete and in contrast to approxlib()).
>     it now never actually plays the move and only uses incremental
>     board data. must be much faster.

Have you verified that indeed it is faster?

I don't really like the exactlib() name. The approxlib() and
accurate_approxlib() names are not all that great either, but carry
around some history. I think I'd prefer to keep the
accurate_approxlib() name unless someone can find a truly good name.

>   - is_self_atari() uses exactlib() instead of playing the move if
>     incremental_sloppy_self_atari() don't know the answer.

Makes sense.

>   - change in the way fastlib() handles captures (generalized). it's
>     #if'ed for now, for there must have been some reason for those
>     conditions. i can't see it, but if anyone can, it will be easy to
>     return to the old version.

Trevor wrote fastlib() and may have some idea.

>   - two new macros in board.c: UNMARKED_COLOR_STRING and
>     MARKED_COLOR_STRING. can potentially replace all instances of
>     UNMARKED_OWN_STRING and UNMARKED_OPPONENT_STRING, but i replaced
>     them only in obvious cases (so far).

I can't see that replacing the UNMARKED_OWN_STRING and
UNMARKED_OPPONENT_STRING macros would improve anything, rather the
opposite.

> regression delta is zero, as it should be. practically, there might
> remain some small bug in exactlib(), since i've had lots of them in
> first versions. if anyone is willing to dig through the code and chcek
> it, that will be great ;)

The normal procedure is to set up an assertion that old and new code
always give the same result and then stress test it. A careful review
is definitely required before this code can go in anyhow. We really
don't want to have occasional errors deep down in the board code.

> now it mustn't be too expensive to replace a call to approxlib() with
> a call to exactlib(). so, if such a replacement gives clear profit, it
> must be at least tried. i haven't looked for examples yet (but hope
> there are some ;).

It seems to me that approxlib() still should be faster. In a few cases
I think approxlib() has been chosen over accurate_approxlib not so
much for speed but because it was more appropriate.

/Gunnar