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

[Gunnar Farneback]

The optics code can be divided into two parts. One which constructs
eyespaces and one which evaluates them. The main component of the
latter part is the function recognize_eye(), which determines the
eyespace value by graph matching, using the patterns in eyes.db.

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.

The current shape of the code is that it's working to some extent, but
it has problems with seki and the issue about deciding which vertices
to play on. There are probably also a few other bugs.

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.

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.

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.

/Gunnar