That confuses me a bit. Why isn't it possible to simply work with unsigned integers (in this case 32 bit), and therefore to avoid any possible errors introduced by "hiding"/"stripping" the sign bit?maksimKorzh wrote: ↑Mon Jan 11, 2021 3:29 pmre: I suppose you use separate 32-bit keys for the signature and the index, since JavaScript doesn't have a 64-bit type. For the signature you don't care what the sign is, it is only used for a comparison of numbers. You want the index to be within the range of the TT, though, which also means non-negative.hgm wrote: ↑Mon Jan 11, 2021 1:53 pm I suppose you use separate 32-bit keys for the signature and the index, since JavaScript doesn't have a 64-bit type. For the signature you don't care what the sign is, it is only used for a comparison of numbers. You want the index to be within the range of the TT, though, which also means non-negative.
Note that the fact that the index key can be negative is self-inflicted. In Zobrist hashing the key is an XOR of all the Zobrist keys. If you had defined all Zobrist keys with the sign bit zero (i.e. positive), their XOR would also be positive. In fact there is no need to do any masking during TT access; you could have done the masking on the Zobrist keys, so that the bits you want to mask away would always be zero to start with.
Didn't exactly get what you mean.
I have my own simple XOR shift based pseudo random number generator to have same hash keys in any environment.
My hash keys are 32bit signed (I tried to make them unsigned via new Uint32Array(hashKey)[0] but after XORing it drops back to being negative)
I assume by "signature" you mean unique position identifier to detect repetitions, if so - yes.
And yes, I want the index to be within the range of TT, Martins solution "(hashKey & 0x7FFFFFFF) % hashEntries" seems to be working fine.
Masking Zobrist key itself is very interesting idea but I like to keep them as they are for simplicity -
I mean when masking is done for tt index calculation it's clear that negative bit is being stripped to fit tt length while
masking Zobrist key might a bit tricky to understand WHY to do that, say someone would like to take my engine
as a bases then long time before implementing tt he would have no use of stripped negative bit in Zobrist key
while it might be an unclear part in the code - I try to avoid code forcing to guess what the author meant.
Only buggy code makes wondering)
My other point is related to your number of hash table entries and its relation to your hash table size. In order to keep both under control you would urgently need to know the exact size of one hash entry in bytes. "80" does not appear to be correct (that would be 5 integers of 16*8=128 bit which I suppose you don't have). If that size is 20 bytes (5 32-bit integers) then your hash table size in bytes should be some (2^N) * 20 where hashEntries := 2^N. So for a 320 MB hash table you would need N=24, for instance. Your index would simply be (hashKey % hashEntries).
with a simple Javascript number - even though there are more floating (ha) around - p4wn does that I think. But I use 2 32 bit ints. Since 2015 ish there has been a Bigint concept in Javascriipt but I've never looked at it in any detail - when I glanced at it I decided it was not useful for hashes, but I may well be wrong. I sometimes plead with the V8 developers to give us native 64 bit ints but it always falls on deaf ears - I even offered them free pizza for life once