gnugo-devel
[Top][All Lists]
Advanced

[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







reply via email to

[Prev in Thread] Current Thread [Next in Thread]