TTs null entries

[wgarvin]

I think what HGM was getting at is that the depth doesn't matter in a QS--it keeps going until it stops.

So (if you are going to store them in the hash table at all) you should use depth=0, both when you store a QS node and when you query the hash table during QS.

[Colin]

Thanks,

So basically if I'm in QS node, and I need to RECORD_HASH, I just need to set the depth as 0, instead of -3, or whatever negative number it is?

I think I get it now, regarding the depth thing, is this correct?..
In an empty entry(thats been initialized so is not null) the key will be 0,
so in the PROBE_HASH code..

Code: Select all

if(entry.key==zobristKey())
{
   if(entry.depth>=depth)
   

The only way the depth condition will be evaluated is if the nodes zobristKey is also 0, which I'm guessing there is a 1 in 2^64=2*10^19 chance, which is low enough for me to ignore.

Conveniently, in java, an objects numerical properties are 0 by default,
so this helps.

Regarding the QS thing above, is this correct?
Thanks

[bob]

I have two bits for the position type... WORTHLESS = 0, LOWER=1, UPPER=2 and EXACT=3. WORTHLESS means the score is unusable, although the best move is OK if present...

Then if you initialize the table to zero, every entry is WORTHLESS.

[Ratta]

Just a question, out of curiosity...
Does it sometimes really happen that you have a move in the hashtable and no value (worthless), not even a bound?
Regards!

[Jacob]

Just a question, out of curiosity...
Does it sometimes really happen that you have a move in the hashtable and no value (worthless), not even a bound?
Regards!

You could seed the hash table with the last iteration's pv to make sure it's searched first, and the "seeds" wouldn't have scores/bounds,...

[Aleks Peshkov]

Just a question, out of curiosity...
Does it sometimes really happen that you have a move in the hashtable and no value (worthless), not even a bound?
Regards!

You could seed the hash table with the last iteration's pv to make sure it's searched first, and the "seeds" wouldn't have scores/bounds,...

Principal Variation nodes have the most EXACT score of any ever visited nodes.

[bob]

Just a question, out of curiosity...
Does it sometimes really happen that you have a move in the hashtable and no value (worthless), not even a bound?
Regards!

I do not clear the hash table. And no, it is not possible to have a "best move"without a score normally. Near the 50-move rule, I will invalidate all the hash scores, but leave the moves there for ordering... and in those cases, the move is good to try, but the scores are ignored.

[bob]

Just a question, out of curiosity...
Does it sometimes really happen that you have a move in the hashtable and no value (worthless), not even a bound?
Regards!

You could seed the hash table with the last iteration's pv to make sure it's searched first, and the "seeds" wouldn't have scores/bounds,...

They should have the score from the previous iteration... no reason you can't store that... And for many of the PV moves there will already be a hash entry...

[PK-4]

Hi all,
Since some programmers here are willing to test tt storing in QS, I suggest a small addition to collect some statistics for the success ratio hash_hits[QS_depth]/hash_strobes[QS_depth] . In my experience the ratio decreases rapidly with increasing QS_depth so that tt strobing at some depth becomes useless. I guess this is so because, barring noncapture checks (if allowed), QS moves are irreversible and change the boardscape rapidly. In contrast, search moves are mostly reversible. It would be interesting to know if others have the same experience regarding the statistics.

P.K.Mukhopadhyay

[Jacob]

They should have the score from the previous iteration... no reason you can't store that... And for many of the PV moves there will already be a hash entry...

*realizes he wasn't thinking and feels like a complete idiot*

What a day :-/