Author: Scott Gasch
Date: 09:45:25 11/21/00
I promised some dumb questions soon... I know that in good move ordering you
should sort the PV moves from the last search ahead of all others in the
generated list. I also know that to do this a lot of folks "stuff" the PV back
into the hash table at the end of a search so that the hash move for the next
search at position P is the PV move from the last search if there was one.
My move selector code first checks whether the move under consideration is the
PV node by looking at the PV structure and, if not, looks to see if it's the
move from a hash table miss. I thought this was redundant since, like others, I
am stuffing the PV back into the hash table. However when I removed the former
test the search tree size ballooned.
I must either misunderstand how this works or have an as-yet-undiscovered bug.
Briefly, what I do is this:
for (depth = 1, depth < MAX_DEPTH, depth++) ...
{
value = Search(pos, depth, a, b);
if game over etc...
stuffPV(pos, PV);
...
}
Where StuffPV just walks the PV, makes each move (to generate the positions's
hash signature) and puts an EXACT entry of depth zero (unusable) in for each
sig. [Should I be hashing with depth and score (score being what was returned
from search and depth being depth-ply?)] Then it unmakes the moves.
My hash table is semi-large (20M) but could I be getting enough collisions to
overwrite PV nodes in it before search gets to this position again? If I take
out the first condition below the search balloons:
// Sort PV moves first.
if (mv.move == g_PV[0][g_iPly].move){
return(INFINITY);
}
// Sort hash moves next
if (mv.move == g_HashMoves[g_iPly].move){
return(INFINITY >> 1);
}
// Then captures by MVV/LVA... etc...
As always, appreciate the help.
Scott
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.