Author: Uri Blass
Date: 11:40:17 09/10/03
Go up one level in this thread
On September 10, 2003 at 11:57:31, Tim Foden wrote:
>On September 10, 2003 at 11:01:30, Uri Blass wrote:
>
>>On September 10, 2003 at 10:23:15, Tim Foden wrote:
>>
>>>On September 10, 2003 at 10:04:24, Uri Blass wrote:
>>>
>>>>On September 10, 2003 at 09:19:25, Tim Foden wrote:
>>>>
>>>>>Hi Uri,
>>>>>
>>>>>In GLC I probe the pawn hash tables every time Evaluate is called (it is probed
>>>>>from withing the Evaluate code). Evaluate is currently only called from the
>>>>>q-search.
>>>>>
>>>>>Cheers, Tim.
>>>>
>>>>I still think that it is a waste of time and maybe it is better to keep a global
>>>>varaible that tells me if to probe the pawn hash tables only when make move
>>>>does not change the pawn structure.
>>>>
>>>>At the end of makemove after I already decided if to probe or not to probe
>>>>I should have
>>>>HaveToProbe=0;
>>>>
>>>>In unmakemove I should have
>>>>if (pawn structure was changed)
>>>>HaveToProbe=1;
>>>>
>>>>When HaveToPtobe=0 in the beginning of makemove
>>>>I can probe only when the pawn structure is changed and in other cases I
>>>>alwaysprobe in makemove.
>>>>
>>>>Uri
>>>
>>>Well, I guess it depends what you do whan you probe.
>>>
>>>E.G. Given something like this (made up so I accept there could be bugs :)...
>>>
>>>struct PawnHashRec
>>>{
>>> unsigned __in64 m_pawnHash;
>>>
>>> // other fields in pawn hash record here...
>>>};
>>>
>>>static unsigned __int64 s_pawnHash; // this is kept up-to-date my makemove()
>>>static PawnHashRec s_pawnProbe;
>>>static PawnHashRec s_pawnHashTable[PHASH_SIZE];
>>
>>If I understand correctly it means that you remember the same information
>>twice(one time in s_pawnProbe and one time in s_pawnHashTable[PHASH_SIZE])
>
>Yes.
>
>>The question is if it is not better to read the information directly from the
>>arrays in s_pawnHashTable[PHASH_SIZE].
>
>The (slight) problem with this is that you'd then need to either re-calculate
>the table index each time, or have some way of testing whether a cached index
>is still relevant, which requires a bit more code again.
>
>Also, the hit rate on the cached s_pawnProbe record should be fairly high (I
>have a vague recollection of someone saying this is around 75%).
>
>Cheers, Tim.
Thanks
one more question:
Is there an advantage for using unsigned 64 bit integer?
I use for my hash tables simple signed 64 bit integer
and I want to know if there is a special reason to prefer unsigned
I do not use unsigned because I learned from bruce's page and he did not mention
unsigned
http://www.seanet.com/~brucemo/topics/zobrist.htm
U64 may suggest unsigned but the comment that suggest to use simply __int64 is
the following comment:
"you define this element yourself, depending upon what compiler you use -- try
"long long" or "__int64"
Uri
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.