Author: Steven Edwards
Date: 21:32:00 05/01/05
Symbolic: Status report 2005.05.02 I decided to have the DecodeEPD ChessLisp primitive support all of the EPD opcodes output by the toolkit instead of just those needed for the genetic algorithm subproject. To my surprise, the end to end testing showed that I had forgotten to write some of the toolkit importing code for scores and time values (used in the "pes" and the "scv" opcodes). This also helped locate some minor anomalies in the CTScore class that have now been fixed. The EPD opcode "scv" means "search clock value" and its single operand is a time value expressed in the form: [[[DDD:]HH:]MM:]SS[.CC] (days, hours, minutes, seconds, and centiseconds) with appropriate leading zero field suppression. It is a substitute (and replacement) for the "acs" opcode; it allows better resolution and is much easier for reading by a human. Inside the toolkit, time values are represented as 64 bit integers containing the microsecond count since the start of the Thompson epoch. The time value lexer properly reads an ASCII time value with greater than centisecond resolution; however, the toolkit time value encoder rounds the precision to centiseconds as that's the best that can be had from the standard library CPU usage routines. I first used this format without fractional resolution in my old program Spector and I've come to be used to it, so I added support for a new chess type (SyChessTypeClock) in the ChessLisp interpreter. The result is greater ease of viewing along with automatic type checking. Two new ChessLisp primitives were added: ClockFromUsec and UsecFromClock to allow access to clock values. Testing of the above was done by running the Lisp test suite loader on a bunch of EPD analysis files. I had a big surprise when the interpreter EPD decoder failed on an analysis record for BWTC.0991; it couldn't recognize the mating move at the end of the PV. After a long debugging session I was able to track down a bug in the frozen man (pinned + unable to move) detector that mistakenly claimed some pinned pawns were not frozen when in fact they were. The bug only manifested itself only extremely rarely, and so that's why it's been in there for over a year. The problem with the frozen man detector affected the move generator causing some pawn moves to be generated in certain very special cases, and this in turn led indirectly to the failure to match the SAN for a mating move in the BWTC.0991 analysis. Anyway, this has all been fixed. It's humbling to say the least that the bug had been undetected for all that time. -------- 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.