[gnugo-devel] Semeai

[Daniel Bump]

I've been working on implementing the Zobrist hashing
in do_owl_analyze_semeai. The version that's up now
does save some nodes but can still crash, so it will
need further revision.

Although the patch is still a little broke I'll
describe the implementation in case Inge and Gunnar
have any comments. The patch can be found at:

http://www.gnu.org/software/gnugo/patches/semeai_1_23.1a

There is a problem with the compactness of the
hash data. BTW, I haven't addressed the problem
Gunnar described in:

http://mail.gnu.org/pipermail/gnugo-devel/2002-January/001123.html

but I'll say that one issue is that we'd like to
save a bit more data than we have room for in the
compressed data. There is a similar issue with the
semeai, which I'll explain.

The function do_owl_analyze_semeai differs from the
other reading and owl functions in two ways. (1) Return
code is void, though this will change, and (2) it
pertains to two dragons. The first difference is
unimportant.

The function returns through pointers statuses for
two dragons and so I split the result field in half.
These statuses can be ALIVE, DEAD, ALIVE_IN_SEKI or
UNKNOWN. Four bits is enough to cache these.

However there is still a problem that the hash key
only depends on one dragon, which could conceivably
be involved in multiple semeais. The solution I found
to this is to run reading_cache_clear() from the
non-recursive owl_analyze_semeai() after
do_owl_analyze_semeai() returns.

If this call to reading_cache_clear() is moved before 
the do_owl_analyze_semeai() call we get a different
set of crashes. I looked at one of those.  It was not
in semeai() at all but a later call to the owl
code. The crash was in hashtable_partially_clear().

I would like to understand these crashes.

At least one of the crashes of the current patch
disappears if reading_cache_clear() is called both
before and after the call to do_owl_analyze_semeai().
This is a crash in lazarus:8. It does not occur if
that test is isolated from the rest of lazarus.tst.

Dan