[gnugo-devel] Escape

[bump]

I've a patch up for discussion at:

http://www.gnu.org/software/gnugo/patches/escape_3_3.1

This is not in the CVS.

In http://mail.gnu.org/pipermail/gnugo-devel/2002-May/002097.html
I proposed that we need more escape patterns in owl_defendpats.db, 
but that we need to modify how we behave during escape. This patch
implements the suggestion of that e-mail, which is to disable calls
to owl_determine_life. It adds a new pattern classification
called 'E' to the escape patterns in owl_defendpats.db. I just
added this classification to every pattern which calls the
owl_escape_value autohelper macro.

The parameter escape is incremented when an owl defense
pattern is matched. Calls to owl_determine_life are not
made when the escape parameter is greater than 2.

This patch has one expected PASS (lazarus:16) and one
FAIL (neurogo:13). The fail is actually a test where
the problem was never truly solved because according to
http://www.public32.com/regress/?neurogo:13 GNU still
values the ko at P7 as worth 20 points, not realizing
that it cannot be fought.

My original message stated that we should add the escape
parameter to the cached results but this is not done
by this patch.

Unfortunately, if one starts adding escape patterns one 
quickly gets a lot of meaningless variations. I think
that when the escape parameter reaches a certain cutoff
value we should declare that the dragon has escaped.
Possibly we should add ESCAPE to the possible results
which would be ordered 0, KO_B, KO_A, ESCAPE, WIN. Since
cache.h budgets 4 bits for the result we could do this.

There are other ways to proceed however. But assuming
we took this approach, the right thing would be for 
do_owl_defend to try to improve an result of ESCAPE to
WIN or that do_owl_attack should try to reduce a WIN to
ESCAPE.

However I don't think we can afford to do that. For 
WIN and ESCAPE must be treated as equivalent because
of time constraints. But at least we can track whether
the dragon lived by escaping. This has the defect that
it might be that a dragon is classified as being alive
or critical with escape when actually another line of
play exists to make life locally. This would be missed
because the escape pattern happens to be tried first.

If this is unacceptable then one could reducing
the escape patterns in value so they are tried
last but implement a policy that an escape move
is tried if one is matched, even if the MAX_MOVES
limit has been reached.

Assuming all this goes well, we could reach a state
where the owl code tries harder than it currently does to
find escapes, and keeps track of whether the group
lived by escaping or making eyes locally. This is
a variation of Gunnar's proposal (2) in:

http://mail.gnu.org/pipermail/gnugo-devel/2002-April/001975.html

The owl code would not be run twice but at least we'd
track whether escape was a factor in the result.

Then one could give priority to defending a dragon whose
life depends on escape.

Dan