probe hash in ply 1 ?

[AndrewShort]

I was just staring at my code and I realized I explicity wrote it to probe the hash at the root, but only to get a possible best move (say, from a previous iteration - the hash table is not cleared between moves nor iterations). In other words, no bounds or exact scores are retrieved from the hash on ply 1. I cannot for the life of me remember why I wrote it that way, but it's so explicit that I must have had a reason.

Can someone englighten me (either my reason, or my error) ?
--thanks!

[Stan Arts]

To avoid overlooking some potential repetition ugliness perhaps? (or other path dependant transposition horizon ugliness transposing to your root transposing right into the middle of your game transposing it all to hell.)
For that reason I also avoid transpositioncutoffs on ply 2 in search. (unless my search/iterationdepth is just 2 ply) If it helps or not I don't know, seems like a reasonable precaution and seems to hardly costs anything. (usually when there are potential cutoffs to be made on ply 2 (usually from last search a move ago) loads of ply 3 and beyond positions are in hash as well and there's no practical loss)

cheers,
Stan

[bob]

To avoid overlooking some potential repetition ugliness perhaps? (or other path dependant transposition horizon ugliness transposing to your root transposing right into the middle of your game transposing it all to hell.)
For that reason I also avoid transpositioncutoffs on ply 2 in search. (unless my search/iterationdepth is just 2 ply) If it helps or not I don't know, seems like a reasonable precaution and seems to hardly costs anything. (usually when there are potential cutoffs to be made on ply 2 (usually from last search a move ago) loads of ply 3 and beyond positions are in hash as well and there's no practical loss)

cheers,
Stan

I don't see how it can be useful. You probe _before_ you search at any ply. What good is it to probe, get a hit, and avoid searching at ply 1? You get no useful information back at all. I simply don't probe nor check for repetitions in SearchRoot() since it is pointless...

[AndrewShort]

what if the call to AlphaBeta at the root is with an aspiration window - would be nice to know instantly, for example, that it's a fail high, with a simple hash probe...you couldn't know that so fast unless you probed the hash at the root

[bob]

what if the call to AlphaBeta at the root is with an aspiration window - would be nice to know instantly, for example, that it's a fail high, with a simple hash probe...you couldn't know that so fast unless you probed the hash at the root

You will make one move at the root, and then get the fail low at the next ply, so the cost or savings is essentially nil, when you think about it. And then you need to special-case it because you can accept fail-high/fail-low hash entries, but you can't stand an EXACT hash hit because you have not yet played a move on the board... It seems more direct to just avoid doing any of that at the root, no hash probe, no repetition check, etc...