[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [gnugo-devel] Post 3.4 cleaning
From: |
Arend Bayer |
Subject: |
Re: [gnugo-devel] Post 3.4 cleaning |
Date: |
Mon, 7 Jul 2003 19:17:03 +0200 (CEST) |
Gunnar wrote:
> 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.
I mostly agree, only two comments:
> * 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.
I do find the "New 3.3.xx (yy)" a bit superfluos because the same
information is available with cvs annotate.
Of course we should _not_ kill comments like "needed for trevorc:400".
> * 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.
I'd like to keep this around. It's a pity that we haven't heard anything
from Tristan for a while, but
- I think it is fundamentally faster than your algorithm (i.e. this is
not s.th. that will go away by tuning your algorithm)
- we might need a very fast readconnect if you want to integrate a lot
more connection reading into owl.
Arend