TalkChess.com

So in my last release of Topple, I added an interesting feature called "move from hash", where Topple probes the transposition table at the root position of a search, and if there is an entry with an exact bound, returns that as the bestmove instantly without any further searching, subject to some conditions:

• The depth of the entry must be at least the root depth of the last search

• The last search must have taken more than the "average" time taken for a search

Here is my implementation of the idea: https://github.com/konsolas/ToppleChess ... #L241-L264

As far as I can tell, this isn't present in any of the top open source engines, but, based on testing, it seems to significantly improve playing strength at short time controls, as it leaves time for other moves to be searched more deeply.

Has anyone else considered/tried this? Are there any caveats I should be aware of?

I have tested it (more or less) already in Minic a few weeks ago without success. Code is commented around line 3428. I took the idea seing another engine starting search at a deep depth and guessing this is due to tt usage...

Success of this technique probably depends on whether lower iterations help in move ordering by setting history values etc. If they help, then iteration right after one that returned hash score can actually take longer than all the skipped iterations together.

PK wrote: ↑Wed May 15, 2019 10:54 am Success of this technique probably depends on whether lower iterations help in move ordering by setting history values etc. If they help, then iteration right after one that returned hash score can actually take longer than all the skipped iterations together.

That's what I though ...

I've run ~ 1000 CCRL 40/4 games and I don't see any significant improvement in Igel:

Score of Igel 1.6.0 64 POPCNT vs Igel 1.5.1 64 POPCNT: 207 - 195 - 423 [0.507] 825
Elo difference: 5.05 +/- 16.54

I think the elo gain will wear off if I do more games (5-10k), so I am not sure it is helping at least in Igel's case.

Maybe this is specific to certain time controls: at a repeating time control like 40/4, engines rarely get under time pressure that this change would help to avoid.

This is something that is supposed to never happen, right? The depth you need in the root is the largest depth of the entire search, so only positions that have been searched at the root before should satisfy the requirement (but then you are already repeating positions, and mindlessly sticking to the loop is probably the last thing you want to do in such a case).

hgm wrote: ↑Wed May 15, 2019 7:42 pm This is something that is supposed to never happen, right? The depth you need in the root is the largest depth of the entire search, so only positions that have been searched at the root before should satisfy the requirement (but then you are already repeating positions, and mindlessly sticking to the loop is probably the last thing you want to do in such a case).

It happens quite frequently in fast games, because the root depth usually isn't representative of the actual search depth.

Most frequently, it happens for recaptures and checks, due to singular extensions and check extensions. So the hash move will only apply if the new position was extended to have the same depth as the root node.