Author: Steven Edwards
Date: 23:10:32 04/24/05
Symbolic: Status report 2005.04.25 A problem in the toolkit SAN check/checkmate indication generation, accidentally introduced a couple of weeks ago, was identified and fixed. At the same time and about the same place there was a moderate clean up of some very old code in the CTMoveList class, and the results are less code, cleaner code, and a very slight speed increase. While fixing the above bug, I also noted and fixed a problem in the move ordering where a promotion pawn was mistakenly thought to somewhat immune to an immediate capture. As is the case with other toolkit modifications, the resulting version is being tested on the ICC. -------- More work has been done on plan representation and plan support utilities. PlanPoint, PlanBlanch, and Goal instances now all have an idea of the corresponding chess position when a definite position exists. It doesn't always exist; it will exist for the root plan point and for all points further down that are separated by a contiguous sequence of PlayMove instances. When it does exist at a point, all that point's immediate outgoing branches and associated goals will also have the same definite position as their "before" position. If the associated goal is a PlayMove goal, then it also has a definite move and so an "after" position can be bound to that goal and its branch. When this occurs, the branch's associated outgoing plan point is also given the "after" position and so on down the line to the end of that subplan path. All of the construction details are encapsulated in a single Lisp goal attachment function; the only somewhat tricky code is a section in KsPlanner that creates the root PlanPoint instance that's needed before any attachments cat be performed. Once the root plan point is in place in an IDB, all subsequent threading and propagation works via the attacher. A related task was also finished; the capability to safely delete an arbitrary subplan. This is needed for plan edits. The deletion has to be recursive while carefully preserving various connectivity and semantic constraints on the global plan structure. This new code appears to be working. I've started work on the Lisp ClonePlan function. This is needed to clone a subplan of a goal when that goal is elaborated into two or more substituting goals. Each substituting goal will get its own copy of the subplan as the plan exploration process will annotate the plan and there is a need to avoid duplicate or different annotations. -------- The Lisp function DisplayRootPlan produces line oriented output to a text stream and this output is not really suitable for web browser style paragraph reformatting. Because of this, dumping the stream straight to the (optionally) generated web page produced a rather sloppy result. To fix this, I added a RawText narration item type that sidesteps browser reformatting by using the HTML "pre" tag. This also has the desired side effect of selecting a monospace font for the rendering of the indicated text. There is a need for further work on narration of planning activity. Some caution is needed when introducing narration support in the knowledge sequencers; a narration paragraph must be started and completed in one function without being interrupted by narration generation in a second function. Another narration issue is when to have a position diagram generated. In Wilkins' Paradise program a diagram is output to the trace only when a position in the search is generated for the first time. This makes for a relatively compact trace, but it can be hard to follow. I'll have to think more about this. To those that question the value of a narration facility, I would draw your attention to the discussions of alleged fakery in computer chess events. (I believe that all such accusations by non programmers are baseless.) When a program can generate an extensive web page narrative in real time and have it available immediately after a move selection, then there can be no reasonable doubt about the veracity of a search. Also to avoid fakery accusations, during ICC play Symbolic always does a kibitz (or whisper if the opponent is a human) of its predicted variation and expectation. Some other ICC computer players do this; I would recommend that all of them should provide this output. I'm also considering the possiblilty, during ICC play, of having Symbolic make its HTML narrative available on a web server in real time, at least in non blitz time control games. Opponents would be honor bound not to peek. -------- More to come.
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.