Re: [gnugo-devel] Critical dragons and cache problem

[Evan Berggren Daniel]

On Fri, 25 Jul 2003, [ISO-8859-1] St?phane Nicolet wrote:

> This is probably a cache problem : as I anderstand it, the last move
> (Black C13) is probably not in the active area used for the owl-reading
> of C16 and C17 when they were put dead in the cache.
>
> But I really think we should do something about critical situations
> like that, because it means we can fine-tune the regression at will
> and still see gnugo play blunders in similar situations in real games.
>
>
>
>
> If this is indeed a cache issue, I can see two ways to solve it :
>
>     1) extend the active area, maybe including second-order liberties
>        of stones used to kill a group.
>
>     2) add a rule in examine_position() which says that any dead
>        opponent worm adjacent to an own owl-critical dragon should be
>        tested owl-critical with the cache, whatever the cache thinks.
>
>     3) any better idea ?
>
>
> I don't know how to do (1) at the moment nor if it is a good idea.
> If nobody objects, I would like to implement (2) and see how it works.

I think step 1 is to begin collecting regression test cases for the
problem.  Since you have a few, perhaps you could start :)  If you're not
interested, I can do it.

The way to do this would be to create a new file cache.tst.  You then need
to create the tests so as to set up the incorrect cache.  To do this, load
to the position a move before you wish to test, run the commands
owl_attack and owl_defend on the relevant dragon to get the old data in
the cache, then load to the position you wish to test and proceed as
normal.  I haven't tested this, but it should work.

Step two is to either find a way to detect such problems like you
suggested, or do a better job finding the active area.  We have always
assumed that being somewhat conservative with the active area was a
reasonable speed / strength tradeoff, but that might not be so.  I don't
think any careful analysis has ever been done.

If you want to go searching for more of these problems, I think the
easiest way is to replay games with the cache disabled.  I think the
easiest way to do this is to set the persistent cache sizes to 0 in the
source and recompile.  When replaying recent nngs games, you can reduce
the amount of noise by using the same random seed; they were played with
the random seed as the date in the filename, not including the year.  eg,
wildcat-gnugo-3.3.23-200307171625.sgf should have been played with seed
07171625.

Hope this helps

Evan Daniel