Re: [gnugo-devel] The life code and the regressions.

[Inge Wallin]

Gunnar wrote:
> In life.c there is an alternative function for evaluating eyespaces,
> recognize_eye2(), originally written by Inge and later revised by me.
> This does the evaluation by actually playing out the position until
> the eyespace is converted into small one-space eyes. This has the
> potential to be more accurate than the graph matching since it
> automatically takes shortage of liberties and corner and edge
> pecularities into account. On the negative side it is significantly
> slower than the graph matching, except maybe for very small eyes. The
> worst problem though is to decide exactly which vertices to consider
> playing on during the examination. For perfectly enclosed eyespaces
> this is not too difficult, although there is a small problem with the
> possible need to play on external liberties. It becomes much worse
> when there are marginal vertices and you may need to allow moves being
> played even beyond the marginal vertices.
>
> ...
>
> A difference from the situation when the life code was written is that
> now the owl code plays a central role in the life and death
> evaluation. (The life code and the owl code were developed more or
> less in parallel.) This has two consequences:
> 
> 1. The weaknesses of the graph matching approach are less important.
> The owl code can work around many of its shortcomings. Recently
> (relatively speaking) the graph matching has also been extended with
> edge and corner specific patterns.
> 
> 2. The owl code requires evaluation of a large number of eyespaces, up
> to a few thousand for a single difficult owl analysis. This makes the
> speed issue much more important than when it was only necessary to
> evaluate the eyespaces on the board once.

I think that to have a really good life and death module we need to
combine the functionality of the current owl code and the life code.
This was my original intention (thus its ambitious name), but as it
turned out Gunnar implemented closing of marginal eye points in the
owl patterns instead.  Going that route more or less closed the
potential of using the life code as it was thought.

At the time I saw that the eye pattern database was continuously
growing, but totally unable to capture all the cases.  We had to have
a dynamic reading of eyes instead.  I started with a simple
implementation (the one that Gunnar described above), with some ideas
to speed it up later.  One way of doing this would be to use eye
patterns as the engine for evaluating eyes at the leaves of the search
tree (e.g. up to size 6).

I don't have any answers for how we could use the life code today.

> The life code is not in active use now, although you can enable it
> with the --life option. My opinion is that it's not a viable way for
> future improvements of the life and death analysis either. Inge might
> disagree, so I won't push for scrapping it entirely at this time.

I am not sure.  You migth be right.

> However, considering the current state of the life code, I can see no
> point in keeping life.tst in the active test suite (i.e. among the
> ones run from "make all_batches"). Furthermore I can see no point in
> keeping the ld_owl_life.tst file around at all, since that is only an
> out of date and unmaintained copy of ld_owl.tst. Unless someone has
> objections, I'll implement this change in a later patch.

No objections here.

        -Inge