gnugo-devel
[Top][All Lists]
Advanced

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

Re[2]: [gnugo-devel] liberty counting


From: Paul Pogonyshev
Subject: Re[2]: [gnugo-devel] liberty counting
Date: Tue, 15 Oct 2002 00:31:09 +0300

Gunnar 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?

well, i haven't, but i can't imagine how playing a move with
all those string reconstructions, stack handling can be faster. i'll
check it.

> 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.

to me, accurate_approxlib() is rather confusing, since it is
"accurate" and "approximate" at one time. but i agree that exactlib()
is not much (or any) better.

>>   - 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.

currently, i replaced only some occurences of UNMARKED_STRING for
otherwise lines of code in exactlib() grew too long. you may notice
that UNMARKED_COLOR_STRING has fewer operations than say
UNMARKED_OWN_STRING. moving string[s].color to a separate variable
should speed the things up a tiny bit (and it is already done in some
cases where we have string[s].color = color; assignment). besides, i
didn't have a known string of appropriate color in exactlib().

>> 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.

the bad thing here is that exactlib() can stop earlier, while
accurate_approxlib() couldn't. i'll remove early returns and do the
check you have proposed. then i'll add them back.

>> 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.

if you meant it should have been faster than exactlib(), then yes. but
the difference must not be too large now. if exactlib() is more
appropriate in some place, it won't be too expensive to use it.

i'm going to submit updated version of the patch tomorrow. i plan to
integrate incremental_sloppy_self_atari() into is_self_atari() (for it
does almost no job now). i have also found two snapback checks (in
snapback() from readconnect.c and attack1()) which can be done with
exactlib() instead of trymove(). however, doing this in attack1() will
affect sgftracing. should i still do it?

Paul





reply via email to

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