Author: Steven Edwards
Date: 19:05:53 03/31/05
Symbolic: Status report 2005.03.31 I've completed the re-work needed because of the deletion of the ChessLisp primitive support for Tree and Node types. This meant the transference of the functionality from the interpreter to the Lisp source. The result: the interpreter source shrunk by over 2K lines while the Lisp source increased by only 500 lines. While the performance has taken a slight hit, there is a worthwhile gain in simplicity and transparency. Symbolic's ChessLisp interpreter has been further simplified by deleting primitive support for the Board type. Anything that could be handled by use of the Board type can be also handled by the primitive support for the Position type; again, a trade of performance for a gain in clarity. This deletion almost certainly marks the last such type removal as all of the other (about twenty) chess specific types are already used extensively by the Lisp source program. -------- The ChessLisp interpreter is not a compiler; it does not produce assembly language level output as would a compiler. However, after a recent modification, it now does perform persistent run time binding of global symbols with corresponding pointers to value bindings. Prior to this modification, every symbol evaluation required a bottom up probe of the activation stack of bindings with each set of bindings implemented as an AVL balanced binary tree. There can be a lot of bindings to search. ChessLisp establishes over eight hundred bindings at startup in the system activation level and Symbolic's Lisp source adds another four hundred at load time in the application activation. A probe requires O(log n) binding node transversals per activation, so it would take a total of about seventeen transversals to first go though the user activation and then the system activation to fetch the binding for a system symbol. Now, a global symbol binding is located immediately. The resulting speed up is about thirty percent. -------- Several more ChessLisp intrinsic predicate functions related to draw detection were added to help make the Lisp production code simpler and slightly more efficient. These include: (DrawFiftyMove? position-value) (DrawMaterial? position-value) (DrawStalemate? position-value) (DrawThreefold? position-value hash-history) and the more general function (Draw? position-value hash-history) plus the twofold triggered detector predicate (IsRepeated? position-value) -------- To assist with the MateAttack productions, I've added the ChessLisp predicate: (DoubleCheck? position-value) which is a minor elaboration on the earlier (Check? position-value) (Checking? move-value) and related to (Checkmate? position-value) (Stalemate? position-value) which correspond to (Checkmating? move-value) (Stalemating? move-value) Several more intrinsics related to MateAttack calculations are planned but not yet fully specified. Some possibilities: (DiscoveredCheck? position-value last-move-value) (DoubleChecking? position-value move-value) (GenerateChecks position-value) (FilterChecks move-value-list) (KingFlightSqCountDelta position-value move-value) (ForcedReply? position-value move-value) (ReplyCount position-value move-value) (InterposingReplies position-value move-value) (KingMoveReplies position-value move-value) (CapturingReplies position-value move-value) (ThreatensMateInOne? position-value move-value) or (GenerateMateInOneThreats position-value) (ThreatensMateInTwo? position-value move-value) or (GenerateMateInTwoThreats position-value) -------- The work on the Lisp Scout object has been finished. Now, each IDB (Instance Data Base, a communal blackboard) has its own Scout for managing short, single path position probes. This has been integrated into the production sets and seems to test out okay. Also, each IDB now has a StageState Lisp object to keep track of what production sets and associated effort levels have been run. This allows greater flexibility in writing the production sequencers; each sequencer knows how to activate any precursor sets and also to avoid execution if it had been previously activated. -------- A new global variable was added to the Lisp source, a PST (position search tree) cursor. A PST cursor in an association list that includes a target tracker and a node among other items and is used to indicate the current processing context. (It replaces the global variable for the general target tracker object.) Having a global PST cursor provides several benefits: 1. It simplifies and speeds the production mechanism by eliminating various context indication parameters (although there is the need to ensure that the PST cursor is pointing at the right spot when a production sequencer is called). 2. By grouping together certain context items, it makes it much easier from a programming standpoint to ensure that these are kept synchronized. 3. The global PST cursor can be outfitted with various debugging aids such as tracers, triggers, and a single stepper; also, statistics counters can be added. 4. Symbolic's narration facility can be connected to the PST cursor so that as the program wanders around the tree, its peregrinations can be output in natural language (and also to an HTML generator). This helps fulfill one of the major goals of the project: a real time proof by explanation that the cognitive search is performing as claimed. More work needs to be done with the PST cursor including a lot of testing. -------- On a rare trip back into the toolkit, I added a PGN game file filter command that removes duplicates. This was motivated in part because testing of the Lisp opening book production sequencer showed that a favorite test position (BWTC.0031) appeared *four* times in the book when it should have appeared but once. Fortunately, this additional work took only a half hour at the keyboard as nearly all of the required functionality was already present in various toolkit classes. As with the toolkit's opening book compiler, the duplicate remover filter looks only at the primary variation of a game's PGN movetext and blissfully ignores the PGN tag pair data. For the gm2600.pgn file from the Crafty ftp site, the filter reports the game counts: Total read: 27202 Total write: 26183 Total duplicates: 1019 (3.75%) For the enormous.pgn file, also from the Crafty ftp site, the filter reports the game counts: Total read: 1496327 Total write: 1400895 Total duplicates: 95432 (6.38%) And for a two million entry PGN file from a different site: Total read: 2000000 Total write: 1872666 Total duplicates: 127334 (6.37%) Merging the above three raw files and filtering the result gives: Total read: 3523529 Total write: 2148177 Total duplicates: 1375352 (39.03%) -------- I've started a side effort to have Symbolic's Lisp source produce an HTML version of its plain text narration output. It's a nice feature to have for debugging. For now, my plan is to produce a single (and rather simple) page per move selection and then use a browser to visually scan through the narration. As with the text narration, the HTML output will (for now) contain only text paragraphs and position diagrams. A related idea is to be able to dump the entire search tree ot a set of HTML pages with hyperlinks (moves) connecting the pages. While the search is expected to be limited to under a thousand positions, that's still a lot of pages if one page per node is written. One possibility is to generate a page for each even ply node and include all immediate odd ply descendants on the same page.
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.