Author: Robert Hyatt
Date: 08:55:16 04/07/04
Go up one level in this thread
On April 07, 2004 at 11:22:56, Renze Steenhuisen wrote:
>
>>Define collision first.
>>
>>(1) two different positions produce the same hash signature...
>>
>>(2) two different hash signatures address the same table entry...
>>
>>(1) should not happen with 64 bit signatures. (2) is common and is why the
>>replacement strategy is so important.
>
>I defined collision somewhere in this thread but it is the same as (1):
>
>from code of DarkSight which is comparable with next.c in Crafty
>/********************/
>
> case HASH_MOVE:
> if( a tt_move is provided )
> {
> tree->stats.hashkey_requests++;
> if( provided tt_move is valid move )
> return tt_move;
> else
> tree->stats.hashkey_collisions++;
> }
>
>/********************/
>
>Or is there something wrong?
Could be something wrong there.
IE if you store a bogus move, you will call it a hash collision when it is not.
Do you use Internal Iterative Deepening? If so, there are opportunities to
store a bogus move if you are not careful. Do you store a "best move" on
fail-low nodes? Same deal. When you store a "best move" check it for legality
at the point where you store it. If you get a legality failure there you have a
bug to fix. If not, then you may have a hashing collision problem...
This page took 0.01 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.