🚀 go-pugleaf

Stuart Cracraft wrote:

	It's easy to criticize but hard to fix bugs, so before you
	criticize software for which the source is freely available,
	consider familiarizing yourself with the code and

		Dig in!

First, I really wasn't trying to be critical--I was just sharing
experience.

I haven't looked at the gnuchess source and I have a large mental
barrier to overcome before I will do so. Basically, with gnuchess (and
any chess playing program) it's extremely difficult to determine if
some behavior actually is a bug unless it's something obvious, like a
fatal signal.

For instance, when it makes a bad move, it's hard to tell if the move
is really bad or what. I'm not even sure that gnuchess unnecessarily
allowing a mate in 1 necessarly constitutes a bug. Most chess programs
rank moves according to how long they postpone mate even when all moves
ultimately lose, but does gnuchess?

I have reported such situations and offered to report more but nobody
has ever expressed an interest. This leads me to believe one of the
following possibilities: 1) its not necessarily a bug, 2) the bug
wouldn't be reproducible anyway, 3) everyone who fixes bugs has
already found more bugs than he can fix, 4) nobody is interested in
fixing bugs, 5) my mail isn't getting through.

I've certainly spent a lot of time identifying and isolating (but not
usually fixing) bugs in other gnu (and non-gnu) software. I'm not sure
bug fixers always appreciate just how valuable or time-consuming that
service is.  Unfortunately, most of that effort has fallen into the
third category above.

I wish I had a way of isolating bugs in gnuchess so that they would be
reproducible. For instance, I'm never sure if just a game record, (or
even a transcript from xboard in debug mode) is sufficient. For
instance, if someone tries to play through the game, how can he make
his machine follow the same path without giving the program different
input? And what about time considerations? And just giving positions
seems hopeless because of gnuchess's use of tables and other info that
persists between positions. Any suggestions?

I've been wondering if it would make any sense to test gnuchess
against itself starting from a position. For instance whenever
anything suspicious comes up in a game, try running gnuchess on the
position with the same amount of time. The idea is that it would then
only consider the position and not be influenced by any corrupted
state info. If it still makes an obviously bad move, then the bug
may be reproducible from the position but allotted time and machine
speed differences may negate even this. And if it does significantly
better, does that imply that something is wrong?

I don't think that just staring at the code without even a
reproducible bug in hand is going to accomplish much. Perhaps you (and
other active contributors) could outline your own testing and debugging
methodology.

--

 Paul Vaughan, MCC CAD Program | ARPA: vaughan@mcc.com | Phone: [512] 338-3639
 Box 200195, Austin, TX 78720  | UUCP: ...!cs.utexas.edu!milano!cadillac!vaughan
----------------------------------------------------------------------------------
I was taxed between $3 to $10 today to pay interest on the national debt.
----------------------------------------------------------------------------------