Author: Steven Edwards
Date: 12:00:50 08/23/04
Symbolic: Status report 2004.08.23 A couple of improvements were made with the recently created CTPost class used for reporting analysis status in connection with the xboard "post" command. First, a final per search summary CTPost instance is sent to xboard in all cases; earlier, some opportunity search conversions to regular searches did not result in a single CTPost when time expired. This also fixed a minor deficiency where no search was performed (e.g., only one move available) and no CTPost instance was sent. This handles a mild problem in xboard's analysis display window; the display isn't automatically cleared when a move is played. Second, when the abovementioned final CTPost object is received by the CTXboard object connected to xboard, a check is made for an ICS connection. If present, a single text line containing a formatted PV and evaluation is emitted as an ICS whisper. ---------------------------- A couple of improvements where made in the CTOpeningBook class. The first change implemented a CTBookHeader class as a base class to CTOpeningBook; this new class supports a 1 KB header on the opening book file containing various formation identification and other magic. This is something that I should have put in at the start but for a failure of foresight. The main part of a Symbolic opening book file is a sequence of fixed length records, each keyed to a single WTM position and containing an eight byte hash key and a nine byte win/lose/draw count record. With the second change, the data layout remains the same; however, the probing is now better than a simple binary search. Now, at book formation time an estimator function is used to calculate the record ordinal of each book entry and its value is compared with the actual position in the resulting file. The minimum and maximum values of the estimation deltas are stored in the book header and are recalled prior to any probing. At probe time the estimator function is called with a position's hash key and the total record count as arguments and produces a guess as to where in the file the desired entry might be. The probe code then applies the estimation deltas to give the initial upper and lower bounds for a binary search using a seek/read/compare loop. The result of this second improvement is nearly a three fold decrease in the number of file seeks over the previous version. More importantly, because the file seeks are now also all much closer together, in practice there is is only one physical disk track seek as usually all the needed file blocks will be on the same track. With a million entry book, the speed improvement observed is roughly a factor of five. There are some ways of further reducing the file seek count, but are not worth implementing as it's hard to get below one disk track seek operation per probe. It would be a different story if the book file were kept on a serial media like magnetic tape; see Arthur Samuel's checker player work from the 1950s for details. ---------------------------- I've added the new class CTTestSuite. Each instance contains as raw data the EPD text records for a common test suite. For now, I've included the suites BWTC, Bloss, ECM, MES, WAC, and WCSAC. A static member function Fetch(SuiteID, RecordIndex) is used to retrieve the desired test suite entry for later work. A new CTCommProc command, "itsrun", will run any of the internal test suites and produce a report as needed. Its operation is something like Crafty's "bench" command with a bit more control and diversity. The intended uses include better automation for: 1. Benchmarking for speed 2. Benchmarking for strength (fixed time search) 3. Internal validity checking (e.g., pathway enumeration) 4. Machine learning
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.