Author: Bruce Moreland
Date: 10:17:28 11/21/00
Go up one level in this thread
On November 21, 2000 at 12:45:25, Scott Gasch wrote:
>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 keep the PV apart from the hash table, so this can't happen to me, but it
shouldn't have happened to you.
Here is the deal. You have your PV, and it contains like 10 moves. You should
be able to go through the PV, generate the positions and the hash keys that go
along with those positions, and then set those hash elements so that the best
move is set to the next move in the PV.
When you do your search, you probe the table for the first node, find the first
node in the PV, search it, probe the table, find the second node in the PV,
search it, etc.
So if we speak that simplistically, I can't see why it wouldn't work.
I think you could get problems if you do other searches before you get to the
bottom of the PV. This might allow the PV nodes to get overwrittten.
>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);
> }
I don't think you want to look at the PV moves unless you are searching the left
edge of the tree. What I mean is that if your PV is 1. e4 e5 2. Nf3 Nc6, you
don't want to search Nf3 first in the third play *always*, just after 1. e4 e5.
bruce
>
> // 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.