Computer Chess Club Archives


Search

Terms

Messages

Subject: Symbolic: Status report 2005.02.14

Author: Steven Edwards

Date: 12:41:38 02/14/05


Symbolic: Status report 2005.02.14

Yes, it has been several months since the last status report.  It has only been
the past couple of weeks that I've been able to do any work on the project.

I've decided to simplify the interactive command processor interface by removing
its opportunity search (i.e., pondering).  A full opportunity search remains in
the xboard interface, however.  The motivation here is to save development time
by leaving out a bug attracting feature where the functionality isn't really
necessary as the interactive command processor is used only for testing and
benchmarking and is not used (primarily) for actual chess play.

A problem in the xboard ICS kibitz/whisper reporting of the PV and score was
located and fixed.  This bug, as noted by several ICC opponents, would on
occasion produce a bogus evaluation in those cases where a only a single move
was available for selection.  As part of the remedy, the xboard post operation
and also the ICS kibitz/whisper function now reports the search termination
status in angle brackets after the PV, much like Crafty reports "<HT>" when its
analysis concludes in its transposition table.  So, in future ICS play Symbolic
will append various search termination mnemonics like "<BookMove>" (an opening
library move), "<TbasMove>" (a tablebase move), "<TimeLimit>" (search time limit
expiration), "<OnlyMove>" (only one move available), etc.

A problem causing much lossage in ICC blitz competition was traced to disk
latency when Symbolic would access its tablebase files the first time in a game.
 It turned out that the disk drive holding the TB files would often spin down
from lack of timely access and go to sleep between games.  Its spin up delay was
so long that it would consume all of the allocated search time and then some on
first access.  I've decided to take the easy and sleazy way out and have a
separate shell script touch a scratch file on the TB drive every couple of
minutes during ICC play to keep the disk spinning.

Symbolic's opening book has been extensively pared of lines less commonly
appearing in master play; this is an attempt to improve overall soundness at a
hopefully minor cost in diversity.  Automated book learning is not yet
implemented and its deployment is not a priority at this time.  Likewise, I've
put off developing six man tablebases (using my custom indexing and generation)
as they aren't central to the AI core of the Symbolic project.

After a long absence from working on Symbolic's internal ChessLisp interpreter,
I'm now adding some new Lisp primitives to make the program's Lisp source run
more efficiently.  One of these functions is the KingFlightBB operation; the
Lisp expression

    (KingFlightBB PositionValueOperand ColorValueOperand)

returns a Lisp bitboard value with the valid flight squares of a king of the
given color in the given position.  While this flight square calculation could
also be done more explicitly via a compound function of more primitive ChessLisp
operations, its use is expected to be common enough to justify its own built in
function.

Another ChessLisp primitive under consideration is FilterMoves; this function
would take a position value, a move list, and a selection specification and
would return those moves in the list filtered by the specification.  The
specification itself can be a complex expression and may deal with concepts like
blocking/unblocking, attacking/defending, and pinning/unpinning.  Like all other
ChessLisp primitives, FilterMoves can be nested, and its results can be combined
with the ChessLisp set operators union, intersection, and set-difference.

Symbolic's ChessLisp source level (the highest, most abstract level of the
project) is seeing the development of a "smart" (vs. brute force) mate finder as
a prelude to a more general and much more complex planner.  This involves the
implementation of a mulitple beam search in an attempt to mimic human search.
As with human search and unlike traditional chess programs, this means keeping
the entire search tree in memory revisiting nodes based on changing interest and
uncertainty.  To help with this, I'm experimenting with a causality facility
(tuned for a checkmating drive) that is needed for forward pruning.

More to come, eventually.



This page took 0 seconds to execute

Last modified: Thu, 15 Apr 21 08:11:13 -0700

Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.