Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Symbolic: Status report 2004.08.23

Author: Gerd Isenberg

Date: 12:17:27 08/23/04

Go up one level in this thread


On August 23, 2004 at 15:00:50, Steven Edwards wrote:

Steven,
do you have some UML-like class diagrams or sequence diagrams how objects
interact during Symbolic's game of chess including search, time control and
pondering?

Thanks,
Gerd


>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.