[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gnugo-devel] dynamic connection status?

From: Gunnar Farneback
Subject: Re: [gnugo-devel] dynamic connection status?
Date: Thu, 17 Jan 2002 21:39:29 +0100
User-agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/20.7 (sparc-sun-solaris2.7) (with unibyte mode)

Dan wrote:
> > For the time being I think it's more constructive to work with the
> > connect/disconnect test cases in connect.tst and connection.tst.
> But I disagree for two reasons: 
> (1) Linking it in has to be done anyway, unless we abandon
> this code and start again from scratch, so why not do it now;

Because linking it in will involve lots of experimentation, which is
much easier to do once readconnect works solidly. 

> (2) We will definitely get useful information by being able
> to play real games using this code. For one thing we will be
> able to use the regressions to identify the moment when
> the new code does more good than harm.
> Incidentally (ignoring timing matters, which I'm testing
> right now) we've reached that point with the experimental
> semeai code, and we wouldn't know that if we didn't have
> the experimental compilation option.

There's a huge difference in complexity between linking in the
connection reader and the semeai code. The latter is limited to an
alternative function call, new_semeai() instead of semeai(). Linking
in the connection reader will involve lots of alternative code,
especially when we start breaking up the amalgamation process.

This notwithstanding, I don't mind if people start doing experiments
with things that can be done on a small scale. But I still think it's
more constructive to improve the connection reader itself at this
time. Unfortunately I don't know how to proceed within Tristan's
design, so unless he adds some input soon I'll try an alternative

If people want to help with this without getting involved in the code
it would be very valuable with additions to the test suite. In
particular systematic tests of standard connection tesujis would be
helpful, similar to the monkey jumps with variations in


reply via email to

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