Author: Steven Edwards
Date: 13:48:32 05/24/04
Symbolic: Status report 2004.05.24 I've added an author component to the analysis structure that is passed among various knowledge sources. The idea here is that the originator KS of an analysis signs that analysis with its name, the node local to the KS at the time, and a KS call sequence ordinal so that appropriate credit (or blame) can be assigned long after that analysis is created. Other than the obvious debugging benefit, the signed analysis is passed to the narration facility to make the narrative more interesting and informative. A future application of the KS analysis author feature is to support a meta evaluation of the KS family, and this in turn can help to reward or punish a KS by modifying its weights or other configuration parameters. Whether or not this automated learning technique is worthwhile (or even feasible to implement) remains to be seen. -------- Nearly all of the Lisp initialization and parameter checking source has been moved out of the Symbolic's main Lisp function and into a separate and more clearly written file. So, the main program source file Symbolic.lsp is now slimmed down to a trim, more readable 108 lines. The parameter checking is not strictly necessary as, during real competition, Symbolic gets its input automatically generated from the calling CTCogSearch object and not via manual interaction. But it doesn't hurt to have a little (and quite fast) one time checking. -------- The ChessLisp interpreter keeps track of a number of performance statistics concerning storage management and evaluation call count. I've now made these visible to the Lisp by adding the sysinfo intrinsic that returns the current value of a designated statistic, and a selection of these have now made it into Symbolic's narration facility. Inside of every Lisp interpreter is the function eval() that performs both symbol value lookup and Lisp function calls, and the eval() in ChessLisp manages up to about 300,000 calls per second on a 700 MHz PPC G3 laptop. This figure includes all overhead, full type checking, and storage reclamation (i.e., the mark/sweep garbage collection). Unlike some Lisp interpreters, ChessLisp's storage reclamation is nearly unnoticeable by the user. When running a simple movepath enumeration function, a 1 GHz PPC G4 counts chess positions at a rate of about 150 KHz and the garbage collector gets called about seven times per second. So, there's none of the periodic "roll over and play dead" behavior seen in some other mark/sweep interpreters. The main reason for this is my decision to trade space efficiency for time efficiency as is suggested by the relatively large amount of memory available today as compared to older implementations. A ChessLisp allocation cell is 20 bytes long compared to an eight byte length in a more traditional implementation; a ChessLisp cell includes a special storage allocation management pointer, four bytes for flag information (this also helps support the high speed run time type checking), four bytes for auxiliary type indication, and eight bytes for Lisp pointer/value storage (this supports 64 bit integers/floats and bitboard values). ------- A sample narrative of Symbolic playing a KBNK endgame against itself can be found at http://homepage.mac.com/chessnotation/Symbolic/KBNK.txt; this includes output for the interpreter performance metrics. -------- Future near term work includes design of two important data structures: the Idea type and the Plan type. The Idea type is used by KsSurveyor; that KS prowls the pattern instance database for the given position and returns a list of ideas to be considered by KsPlanner for making plans. KsPlanner looks at the idea list and the position, does further pattern matching, somehow comes up with a list of plans, and returns the list to KsSelector for ordering. KsSelector gives the plan list to KsExplorer which in turn deals them out, one at at time, to KsExplorePlan. KsExplorePlan fools around with a plan, the instance database, the search tree, and applies various magicks and superstitions to come up with an analysis that is returned to KsExplorer. KsExplorer does the minimaxing, some guesswork, a lot of recursion, and eventually returns the most promising analysis to KsSelector. In turn, KsSelector feeds a filtered version of the analysis to its calling KS. If the calling KS is KsCandidateSelector, the tentative move to be played is taken from the analysis. Time management is performed by KsCandidateSelector (each time through the effort increment loop), by KsExplorer (but only when it's at the ply zero level and deciding if to try exploring a new plan), and by the KS Manager (at each KS call to see if the drop dead hard time limit has been exceeded).
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.