🚀 go-pugleaf

In article <VAUGHAN.92Jun10103925@bock.cad.mcc.com> vaughan@bock.cad.mcc.com (Paul Vaughan) writes:
)
)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?

Gnuchess should postpone mate.

)
)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.

1) happen often enough.
2) can be helped by not using a transposition file &
   by using depth rather than time to limit search.
   This would also make some bugs not happen.
   Also searching on opponents time is no good for
   reproducibility, maybe these nodes should be listed 
   too.
   It would take some extra code to be able to use the
   game-list (with time limits) info about number of
   nodes.
   Maybe adding a -DREPRODUCIBLE
   forcing easy to be on all the time +
   no transposition file usage +
   forcing 1 second to be exactly 1000 nodes long
   would do the trick.
3) all of us are not there yet, even though I am.
4) I fix small simple easily identified bugs, Mike
   mwm@hslrswi.hasler.ascom.ch take care of the hard ones :-)

)
)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?

Including the patchlevel in the report is helpful.
Turning off the transposition table using "hash" would help tell
if the problem is related to the transposition table.

)
)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.
)

Maybe including a file on how to report a bug would be helpful.
Letting different versions play each other is a good way to
find bugs of the "stupid move" type.
At least if one of the versions don't have this bug that is.
Short games are also suspicious.

)--
)
) 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

-- 
Urban Koistinen - md85-epi@nada.kth.se