Author: Tim Foden
Date: 07:29:13 12/07/03
Go up one level in this thread
On December 07, 2003 at 08:46:59, Dieter Buerssner wrote:
>On December 06, 2003 at 06:05:28, Tim Foden wrote:
>
>>In GLC the move takes 23 bits, and the score takes 20 bits and the draft takes
>>12 bits, and I like to have the full 64 bit hash key in the record, and I don't
>>want to go over 16 bytes for the whole record. I have 3 bits to spare... :)
>
>I use 16 bits for the move (15 would be enough), from (6), to (6), promotion
>piece (3) (and "overlayed" some special states, like "this score was from TB").
>From this, I can regenerate the full move info (including ep/casting/capture
>flags, etc.) with not too much work. Because I will do a full verify of the move
>anyway in case of cutoff, it is almost free. Lower 15 bits of my full move are
>exactly the same as the move I store in the HT, so basically no "compression
>overhead" at store time. As we both know, one could of course even compress
>better.
I've looked at 2 "move compression" schemes for GLC, one that compresses to 16
bits and doesn't need a position array for decompression, and one that
compresses to 12 bits but does need a position array for decompression. Both of
these schemes require quite a lot of code for decompression with GLC. The 16
bit one is also slow at compression.
However, they still wouldn't free up enough space for 2 bounds. I've decided
that the first thing to do with 2 bounds though is to see if it makes any
difference at all. For this, I can just add another 32 bits to the hash record.
I've actually started some of the implementation, but whether I'll finish it
any time soon is unknown... I've lots of other things I also want to try. :)
>I store only 32 bits of the hash key. For score, I need 16 bits at the
>moment, but I am intending to make this 24 bits. The idea is to use 8 additional
>bits in case of draw score, for example to prefer a pos with better eval in case
>of a TB-draw.
I've also partially implemented this in GLC at some point. The idea being to
rate draws by their distance away. I just had a single bit flag in the hash
record to say whether or not it was a draw score. I then
compressed/decompressed as required. I didn't really get it to work properly
though, so I'm currently not using it.
As part of this I thought it may be better to simply use the range -1 pawn to 1
pawn for this instead. Then there would be no compression required at all. All
+ve material values would have 1 pawn added, and all -ve ones would have -1 pawn
added.
>But perhaps this can also be done for storing the scores with the
>16 bits (but that would need another compression/decompression step for
>storing/retrieving the score). At the moment, I use 12 bytes for one HT-entry
>(with a bit of space left), and 16 should be enough for 2 bounds.
>
>What bothers me, is that I have too many calls to probe (in absearch and I have
>3 different qsearch functions). The cutoff logic is not in the probe function
>itself, but rather in the caller (because things are done slightly different at
>the various levels). So, there are a lot of places, where I have to change
>something. I of course should think about a better design for this (without so
>much redundant code).
>
>>I realise that I could store approximate values for the score and the depth, and
>>I could compress the move, but I can't be bothered (I've actually tried move
>>compression though).
>>
>>
>>class CHashTableRec
>>{
>>#pragma pack(push, 1)
>> UINT64 m_hash; // 8 hash key for record
>> UINT32 m_info1; // 4 age, draw flag, score type, move
>> INT32 m_info2; // 4 score, depth
>>#pragma pack(pop)
>>
>>// the info words look like this:
>>//
>>// ------------- m_info2 ------------- ------------- m_info1 -------------
>>// ssssssss ssssssss ssssdddd dddddddd / aaaatt00 0mmmmmmm mmmmmmmm mmmmmmmm
>>//
>>// key:
>>// s = score, in millipawns, signed
>>// d = depth, in eigths of a ply, unsigned
>>// a = age indicator, 0 -> record not used
>>// t = score type, none, exact, upper or lower
>>// m = move
>>
>>Mantis will only use 14 bits for the move, 15 bits for the score, and 10 bits
>>for the depth. 14+15+10+4+2=45, leaving 19 bits. not quite enough for another
>>depth and score, but if we have 2 bounds, we don't need a the flag bits, so
>>14+30+20+4 = 68. 4 bits too many. If I drop a couple of bits from the depth,
>>so it's only accurate to 0.5 ply, then all this would fit :)
>
>Or don't store all 64 bits of the key, of which typically many are redundant
>anyway (if you calculate the index to the table from the key)?
True. I used to do this, but it became hassle when I moved to copying one
record to a (possibly) different position (in the larger table... needs another
bit from the hash key for the index). I may consider it again if the 2 bounds
thing looks good.
Cheers, Tim.
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.