Author: Steven Edwards
Date: 13:45:03 08/22/05
Symbolic: Status report 2005.08.22 Symbolic needs to know about mobility and safety concepts for its higher level reasoning; here are some of the implementation notes for the toolkit classes and ChessLisp intrinsics which assist in this area. Lossage: Symbolic's C++ toolkit has a CTExchanger class that is used to determine the lossage of a man on a given exchange square; this is the (always non positive) score associated with the en prise status of a man. It includes a somewhat non trivial exchange evaluator that returns a value of zero for a safe man and an appropriate negative value for a man subject to a losing exchange sequence. It is available from ChessLisp as the intrinsic: (Lossage position exch-sq) Swapper: The toolkit has the class CTSwapper that performs a static exchange analysis similar to CTExchanger except that the exchange square is allowed to be vacant and the square of the first mover/attacker can be specified. The value returned is the expected gain or loss associated with swaps on the exchange square. It is available from ChessLisp as the intrinsic: (Swapper position exch-sq fatk-sq) Pins: For pin detection, there are two sets of routines. The first set calculates all pins for a given color at the same time; the second set calculates the pin status for a single man. For these routines, only pins against the same color king are or interest as they determine absolute mobility. The first set camputes three bitboards (for a given color): a bitboard of all pinned men, a bitboard of frozen men (the pin direction not being a move/capture direction of the pinned man, and the bitboard difference giving restricted men (pinned along a move/capture direction). Note that a pinned knight is always frozen and a pinned queen is always restricted. This set is used during move generation activity to help ensure that only legal moves are generated and presented to the rest of the toolkit (and the interpreter). The second set is composed of a single routine that returns for a given man an enumeration value of unpinned, frozen, or restricted. It's used for all pin identification outside of move generation operations. Results from both sets of pin detectors are avaialable via ChessLisp intrinsics: (PinFroResBB position) ;; return a list of (pin/fro/res) bitboards (PinStat position sq) ;; return 0/1/2 (unpinned/frozen/restricted) Destinations: A destination bitboard is calculated as the union of all to-squares of a given man. A single routine in the toolkit with code rather similar to a stripped down move generator produces this with the assistance of the single man pin detector. The result is also available via the ChessLisp instrinsic: (PcBBDestinations position sq) ChessLisp has mapping functions that translate between bitboards and lists of squares as needed: (SqListFromBB bb) (BBFromSqList sq-list) Usually, but not always, the bitboard representation is preferred. Mobility: A mobility bitboard for a given square is calculated as all the destinations of the man on that square such that the expected lossage is zero. It represents a first order approximation of the "safe" destinations for a given man, and the calculation can be activated by a ChessLisp instrinsic. This supports trapped man detection; a man is trapped if its mobility bitboard cardinality is zero. The ChessLisp intrinsic is: (PcBBMobility position sq) Comparison with Paradise: The above concepts of en prise and mobility are compatible (identical?) to those seen in Wilkins' program Paradise. The major implementation difference is that Symbolic calculates these attributes efficiently using C++/bitboards while Paradise generates the values using the more time consuming and non chess specific MacLisp functions (and without bitboards). Another difference is that Symbolic doesn't have separate instance kinds (i.e., pattern templates) comparable to the ENPRIS/MOBIL patterns in Paradise; the en prise status and the mobility bitboard of a man are attached as attributes on the corresponding IkMan (Instance kind: Man) instances. The above instance attachment helps speed higher level pattern recognition. In the trap attack plan suggestor of Paradise, the production system has to look at instance kinds for pieces, squares, enpris, and mobil to come up with ideas to attack men that are trapped but not en prise. Symbolic needs to look only at its Man instances, and it does this quickly with a single line in its production language: (InstVar $PMan0 IkMan (PasMover IsQRBN IsNotEnPrise IsTrapped)) Because Symbolic threads together instances of different kinds as appropriate, it's also possible for a single production line to match, say, all squares with en prise men. Or, a single line can match all moves that capture an en prise man. Anytime a production can look at one instance variable instead of two or more, a big speed improvement is gained. -------- More to come on the production system.
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.