Author: Geoff
Date: 15:10:41 06/28/03
Hello
Thanks to everyone for the replies to help me on this infernal mate score hash
problem.
I changed the code as per the suggestion to adjust mate scores for all
checkmates either exact or upper or lower bounds. Unfortunately this didnt fix
the problem.
I am still puzzled by the fact that at hashInsert time the correction as it
currently is can adjust a mate score to be greater than +CHECKMATE or less than
-CHECKMATE. My checkmate score is 10000, from debug I can see that it sometimes
stores in the hash table an adjusted score of 10,002 10,005 etc.
This is puzzling me, can anyone confirm that this is a bug or OK ?
Recapping , my hash inser adjust code looks like this
/* Adjust mate scores so they are not relative to the position... */
if (eval > (INFINITY - MAX_PLY)) /* > 9,900
{
eval = eval + ply;
}
else if (eval < (-INFINITY + MAX_PLY)) /* < -9,900 */
{
eval = eval - ply;
ph->debugEvalAfterAdj = (S16)eval;
// return FALSE; /* dont hash mates as I cant fix it */
}
Hello
I have been adding hashing to my work in progress engine. It didn't take me too
long to get implemented except I have one nasty bug I don't really understand.
The annoying part is that I read several messages in the archive explaining how
to correctly store mate scores in the hash table. Despite this it is still very
buggy when I enable storing mate scores, throwing away easy wins to 3 fold
repetition draws.
Essentially I add or subtact ply to the mate score before storing in the table,
this should store it relative to this current position not relative to the
root. See code below
Note I am only adjusting an exact score and leaving a low or high score
unadjusted. Not sure if this is correct?
#define CHECKMATE = 10,000
BOOL hashInsert(U64 hashCode, S32 eval, move bestMove, S32 depth, U8 flags)
{
pHashEntry ph;
ph = PHASH_ENTRY(hashCode);
if ((ph->code != hashCode) &&
((ph->flags & VALIDITY_FLAG_MASK) == VALID_FLAG) &&
(ph->depth > depth))
return FALSE;
/* Adjust mate scores so they are relative to this position */
if (eval > (INFINITY - MAX_PLY)) /* > 9,900 */
{
if ((ph->flags & BOUNDS_MASK) == EXACT_FLAG)
{
printfDebug("Big Eval ply = %d depth = %d evalBefore = %d, evalAfter =
%d\r\n", ply, depth, eval, eval + ply);
eval = eval + ply;
}
}
else if (eval < (-INFINITY + MAX_PLY)) /* < -9,900 */
{
if ((ph->flags & BOUNDS_MASK) == EXACT_FLAG)
eval = eval - ply;
/* Add info to the table */
etc etc
Then when this position is found again later at some other ply, the ply is
either adder or subtracted to get the correct mate in x from the root position
Running this code with search depth 8, I get for example
Big Eval ply = 5 depth = 0 evalBeforeAdjust = 9993, evalAfterAdjust = 9998
I read this as we found a mate for us that is 7 ply from the root, but we
discovered it at ply 5 of our search, so it is in fact 7 - 5 ply down from this
current position hence store CHECKMATE-2 in the hash table.
The other output I get from this test was as below, I dont really understand
this it is saying I think, that at the leaf node (depth 8) we have found a mate
in the q search at 5 ply from the root ?????? This then causes the adjustment to
store CHECKMATE+3 in the hash table. Is this possible or a bug ?
Big Eval ply = 8 depth = 0 evalBeforeAdjust = 9995, evalAfterAdjust = 10003
Clear as mud huh ? ;-)
Any help in explaining what is happening here or spotting my misunderstanding
would be much appreciated. Thanks guys !
Regards Geoff
--------------------------------------------------------------------------------
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.