Author: Robert Hyatt
Date: 08:02:38 08/25/99
Go up one level in this thread
On August 25, 1999 at 03:30:08, James Robertson wrote:
>On August 25, 1999 at 01:04:08, Robert Hyatt wrote:
>
>>On August 24, 1999 at 22:02:33, James Robertson wrote:
>>
>>>I was looking at my code and noticed that I never get any cutoffs when there is
>>>no available hash move. I modifed my code a little, and it sped up, but then I
>>>noticed tactical problems; on a certain test position it never finds a fairly
>>>obvious move. Anyway, here is my hash code in my search function.
>>>
>>>The third line checks to see if the hash move is legal. Since an UPPER flagged
>>>position may occassionally have no move, the 'blank move' is considered illegal
>>>and it skips any chance of a cutoff. I changed line 3 to
>>>if (!hr.move || board.IsLegal(hr.move)) {
>>>and got the problems I mentioned above. Can anyone help me with this?
>>>
>>>Thanks,
>>>James
>>>
>>> HashRec hr;
>>> if (!hash_move[ply] && hash_table.Probe(&board, &hr)) {
>>> if (board.IsLegal(hr.move)) {
>>> // Adjust mate score.
>>> if (hr.score > MATE>>1) hr.score -= ply-1;
>>> else if (hr.score < -MATE>>1) hr.score += ply-1;
>>> if (hr.draft >= depth) {
>>> if (hr.flags & EXACT) {
>>> return hr.score;
>>> } else if (hr.flags & UPPER) {
>>> if (hr.score <= alpha) return hr.score;
>>> } else if (hr.flags & LOWER) {
>>> if (hr.score >= beta) return hr.score;
>>> }
>>> }
>>> hash_move[ply] = hr.move;
>>> }
>>> }
>>
>>
>>Before I try to understand your code, here is how it ought to work:
>>
>>in the top of Search(), you call hashprobe() or whatever you call it, and
>>you make the cutoff decisions there regardless of whether there is a hash
>>move or not.
>
>That sentence right there answers my question. But when I tried doing this, I
>found I missed a simple tactic in a certain position. So my problem must be a
>freak hash collision, or a bug elsewhere. Do you check for hash collisions? What
>are the odds of a hash collision with a 64 bit number?
>
the odds are _very_ small if you are sure your random numbers are reasonable.
Are you checking the 'draft'? IE the depth of the entry stored in the table
must be >= the remaining depth left in the search before you can use this
entry?
When you store, you aren't screwing up and storing the wrong depth value? IE
you must store the _original_ depth passed into search at this node, _not_ the
value you might have modified with extensions. That will make the entry look
like it represents a deeper search than it really does...
>James
>
>
>>IE if probe() returns EXACT you just return that score...
>>
>>here is the relevant code from Crafty (search.c):
>>
>> switch (HashProbe(tree,ply,depth,wtm,&alpha,&beta,&threat)) {
>> case EXACT:
>> if(alpha < beta) SavePV(tree,ply,alpha,1);
>> return(alpha);
>> case LOWER:
>> return(beta);
>> case UPPER:
>> return(alpha);
>> case AVOID_NULL_MOVE:
>> do_null=0;
>> }
>>
>>
>>Forget the "avoid null" case for the moment. Notice that if HashProbe()
>>returns a non-zero value, it means that the 'draft' (depth) of the entry was
>>fine, and that one of the following three things happened after the depth was
>>tested and found ok:
>>
>>return EXACT if the score in the table is an exact score.
>>
>>return UPPER if the bound in the table is marked as UPPER and it is >= than the
>>current beta value.
>>
>>return LOWER if the bound in the table is marked as LOWER and it is <= than the
>>current alpha value.
>>
>>After you do the above tests, _then_ you start searching moves. And the
>>first move you should search is the move from the hash table. But it has
>>_nothing_ to do with whether you take a cutoff now or not...
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.