Author: Steven Edwards
Date: 20:11:08 09/09/03
Go up one level in this thread
On September 09, 2003 at 22:22:32, Dann Corbit wrote: >On September 09, 2003 at 18:33:22, Steven Edwards wrote: >>5. The centipawn evaluation operand type probably needs to be deprecated and >>replaced with a pawn evaluation operand type with a provision for sub-pawn >>decimal resolution. >perhaps ced instead of ce. Yet not everyone uses centipawn units. The SPCT (Steven's Portable Chess Toolkit) uses micropawns for all internal operations except for a centipawn mapping for transposition table entry storage. At the moment I'm thinking of using "pes" (pawn evaluation score) and reporting it as a real (i.e., with radix point) value. Side note: The SPCT has classes for both scores and for the alpha beta scoring window. Here's a snippet from the CTScore class header file: // Special score values #define CTSValNInf ((CTScoreValue) 0x80000001) // Negative infinity #define CTSValPInf ((CTScoreValue) 0x7fffffff) // Positive infinity #define CTSValBust ((CTScoreValue) 0x80000000) // Broken #define CTSValEven ((CTScoreValue) 0x00000000) // Balanced #define CTSValLose (CTSValNInf + CTMatePlyLen) // Active color is checkmated (lose in zero moves) #define CTSValMate (CTSValPInf - CTMatePlyLen) // Active color has a mate in one move The SPCT handles mate-in-N and lose-in-N for values of N up to 4096. It also handles negative values of N for comparing mate/lose scores at different depths in a search. The idea is that a mate/lose score is treated in an absolute sense and not relative to the depth at which it was detected. The relative depths of mate/lose scores are handled at the time and place of the comparison; thus the need for having score representations fot negative values of N. (Note that these should never exist outside of a program, nor inside of a transposition table entry. But it does, with the help of a few good class methods, eliminate all the annoying bugs that can be attributed to storing mate/lose scores in the TT or to the passing of values up and down a search tree.) >Approximate depth of analysis in plies (acd is what Crafty uses, dep for Hiarcs. > An essential field for me). Your own SAN kit for use with crafty supplied this >valuable information. For me it is crucial (without it, the ce is practically >meaningless) The "acd" opcode (analysis count: depth) was in the specification from a very early date. In Spector, in was the index of the last iteration of a search. >Approximate number of nodes for analysis (acn is what crafty uses). This is >very valuable if I have two records that have the same depth. If one has a >larger node count, it is probably better data (if the engine does not change). The "acn" operand is an example of the need for supporting 64 bit interger values. >For positions where e.p. capture is not possible, it is very bad to have the >field tagged with an e.p. square. Quite frankly, that part of the standard was >broken. Yep, you're right. Mea culpa. Nolo contedere. >A formal standard for a compact binary format would be nice. I have some >suggestions there. I'd be glad to see your suggestions. But the case for the need of a compact binary format (it was called "PGC" in the old specification) must show why today's gzip and its friends are significantly less suitable. A few percentage points of improvement in speed or size may not be worth the burden of having to support a baroque coding mechanism.
This page took 0.01 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.