Author: James Swafford
Date: 07:26:44 05/11/04
Go up one level in this thread
On May 11, 2004 at 09:55:42, Jeff GAZET wrote:
>>On May 11, 2004 at 05:54:52, Jeff GAZET wrote:
>>
>>>Good morning,
>>>
>>>i have some questions about the move to add into the hashtable (see code).
>>>When doing a null move, i don't know which move to insert ?
>>>At the end of the search() function, the "bestmove" can be null. So in
>>>TTableInsert(), if the move is NULL, we should return immediatly ?
>>>
>>>And another question: the score added to the hashtable depends on the side to
>>>move, so we should use 2 transpositions tables ? or returning +-score ?
>>>
>>>Thanks.
>>>
>>>search(...)
>>> {
>>> bestmove=NULL;
>>> ...
>>> if(it's all right for a null move)
>>> {
>>> do_nullmove();
>>>
>>> if(depth-R<1) {eval=-quiesce(-beta,-beta+1);}
>>> else {eval=-search(depth-R-1,-beta,-beta+1,false);}
>>>
>>> undo_nullmove();
>>>
>>> if(eval>=beta)
>>> {
>>> // what should be bestmove here ? as bestmove is NULL actually
>>> TTableInsert(depth, eval, hashfBETA,bestmove);
>>
>>
>>That seems very wrong to me. I don't even do inserts after null
>>moves (not sure why; maybe I just haven't tried it). You just
>>did a search to a reduced depth (R), so 'eval' represents the score
>>returned by that reduced search. Storing the current position
>>with 'depth' will break things I think.
>>
>>On your original question: why store a move at all?
>
>To sort moves. But i'll see that later, i no longer add a move actually to the
>transposition table. But i still have a something strange :
>If i clear the hash table before each search(), moves played are all right.
>Otherwise, moves are bad.
I think you misunderstood my question: I wasn't asking "why store
moves?" as a general question- but specifically for this case.
Keep in mind there are (at least) two main uses for hash tables:
to store scores (bounds or exact) and to store moves, presumably
to help with move ordering. In this case, if you are going to
do a hash insert, you simply don't have a move to store, so
don't try to come up with one.
>Do we need a table for each side ?
No. Side to move is part of a position, and hopefully you're
taking that into account when you build your hash key. If so,
positions that are identical with the exception of side to move
won't produce the same hash signature.
Hope that helps,
--
James
>
>> If you
>>don't have one, just don't insert one. Later, if you get a
>>hash hit, you'll have bounding information w/o a move to try.
>>
>>--
>>James
>>
>>
>>
>>> return eval;
>>> }
>>> }
>>> ...
>>> for(each move)
>>> {
>>> domove(themove);
>>> eval=-alphabeta(depth-1,-beta,-alpha,true);
>>> undomove();
>>> if(eval>alpha)
>>> {
>>> bestmove=themove;
>>> if(eval>=beta)
>>> {
>>> // bestmove!=NULL here
>>> TTableInsert(depth, eval, hashfBETA,bestmove);
>>> return eval;
>>> }
>>>
>>> alpha=eval;
>>> }
>>> }
>>>
>>> // bestmove can be NULL here or can be the last "bestmove" found in for(each
>>>move)
>>> TTableInsert(depth, alpha, (alpha<=orig_alpha)?hashfALPHA:hashfEXACT,bestmove);
>>>
>>> return alpha;
>>> }
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.