[gnugo-devel] Post 3.4 cleaning

[Gunnar Farneback]

In order to keep the sources maintainable (and accessible to
newcomers) it is necessary to regularly clean out obsoleted and
otherwise unused code. Currently there's quite a lot of code which is
no longer of much interest. I propose to remove the following pieces
of code, but not until after GNU Go 3.4 is out. Some of them might be
somewhat controversial, so please tell if you disagree about them.

* unused komaster schemes

When the komaster schemes were developed it was very useful to be able
to quickly change between them. For more than a year now komaster
scheme 5 has been default and doesn't seem to have any problems so
this is no longer of much interest. This would remove some 600 lines
in the very central board code.

* support for !experimental_connections

Experimental connections, which (currently) affect how the dragon
amalgamation is performed, have been default since 3.3.11. Removing
support for nonexperimental connections would simplify code in several
places, primarily in dragon.c, shape.c, patterns/connections.c, and
conn.db. It can be argued that it's still valuable to be able to see
where the experimental connections fail but the non-experimental
don't, but on the whole I don't think this is worth the added code
complexity any longer. It seems very unlikely that anybody would want
to work on improvements of the old code.

* old semeai code

The experimental semeai code works well enough now that we no longer
need the fallback to the old semeai code. Clearly nobody has had any
interest in improving the old code for several years now.

* small_semeai()

Small_semeai() was disabled when it became clear that it was causing
significant trouble without giving much, if any, benefit anymore. I
think it's clear that it does not represent a viable approach and that
further improvement in understanding of small-scale semeais must be
integrated directly into the tactical reading.

* interface/html/*

The code in this directory implements a cgi interface for GNU Go which
works by starting a GNU Go process for each move and feeding it an sgf
file of the moves so far. This code is very old (it was designed for
GNU Go 2.4, almost 4 years ago) and I'm not sure whether anybody has
used it for a long time or whether it even works anymore. The mode of
operation does not take any advantage of the persistent caching
schemes and I'm doubtful that it's a reasonable setup at all
considering the relative slowness of modern versions of GNU Go. If
there is concensus I think we could remove this before 3.4.



There is also a number of potential candidates for cleaning which I
propose that we keep around, at least for now:

* revision comments in the patterns

In GNU Go 2.x pattern tuning (mostly by me and Dan) was quite
intensive and revision comments were accumulating quickly, causing a
need to clean them up from time to time. In 3.x pattern tuning is no
longer of such central importance and my experience is that the
revision comments are now much more valuable than they are
distracting. A lack of revision comments is generally more distressing
than an abundance of revision comments. I propose that we do NOT
remove any pattern revision comments at this time.

* alternate connections

We currently have two connection reading algorithms. One started by
Tristan Cazenave and one by me. The first one is not used and does not
seem likely to get any further development. I still propose to keep it
around for a while because
- it's well isolated code-wise,
- it's faster (but less accurate),
- it's still interesting to see how the regressions and run times are
  affected by switching algorithm. 

* experimental pattern based tactical reading

Trevor added experimental code to do pattern based tactical reading in
early 2002 but no work has been made on this for well over a year now.
If I remember correctly this currently works about as well as the
usual tactical reading but is much slower. I propose to leave it
around for a while longer but if nobody takes interest in it, it's
difficult to motivate why it should remain. The total amount of code
and patterns needed by this is not insignificant.

* tree-based pattern matching

This was introduced by Trevor while developing the pattern based
tactical reading code in order to speed up the pattern matching. It is
unclear whether this is still interesting after various improvements
of the dfa code for pattern matching. Actually I'd like to get rid of
this code which in particular gets in the way in mkpat.c but I'm
unsure whether it's reasonable to make the effort of trying to make
the experimental reading independent of it. It's probably better to
keep this around until either the experimental reading gets removed or
someone continues the development of it and can determine the value of
the tree-based pattern matching.

* debugboard

While being an interesting proof-of-concept, it doesn't seem like
debugboard is much used, if at all. I propose to keep it around until
we have some better tool of that kind, but no longer.

Comments?

/Gunnar