My commentary:
https://youtu.be/uC9cwqyT3uI

I find it utterly bizarre that a powerful chess engine can't recognise a simple transition of moves. You'd think that that would be a really useful ability for a chess engine to have in order to cut down the number of branches it has to evaluate.

Unfortunately, no one in the Stockfish community of programmers has currently figured out a way to do it without impacting the overall tournament performance of the program. I have seen improvements in tournaments of thousands of automated games that were a fraction of an ELO point accepted as a modification. But unless it improves overall tournament performance in a performance test of thousands of games, the improvement - however well-intended - gets rejected.

Stay tuned, as this idea has merit and it is likely that where there is a will, there is a way to do it.

For example, this recent modification to the Stockfish code used a 788,000 game tournament to 'fine-tune' a certain internal parameter, then 2 additional tournaments of 32,000 games to confirm a net improvement of less than 2 ELO:

Author: bmc4
Date: Sun Jan 31 16:00:06 2021 +0100
Timestamp: 1612105206

Tune ordering of moves at internal nodes

We change the relative weights of the function used to order quiet moves in our MovePicker class.

Passed STC:
LLR: 2.94 (-2.94,2.94) -0.25,1.25
Total: 32184 W: 2936 L: 2773 D: 26475 Elo +1.76
Ptnml(0-2): 115, 2196, 11328, 2317, 136
https://tests.stockfishchess.org/te...

Passed LTC:
LLR: 2.93 (-2.94,2.94) 0.25,1.25
Total: 33088 W: 1292 L: 1149 D: 30647 Elo +1.50
Ptnml(0-2): 14, 1030, 14318, 1163, 19
https://tests.stockfishchess.org/te...

The new weight were chosen after the following SPSA session: https://tests.stockfishchess.org/te...

Closes https://github.com/official-stockfi...

click for larger view

Stockfish_21013116_x64_modern:

<83/37 3:25:29 0.00 43.Bc2 Bh5 44.Bd4> Kf7 45.Bd1 Kg6 46.Bc2+

<RandomVisitor>Transposition detection is a good idea and would seem to be a way to save search time and therefore result in stronger performance.

The current hash table provides a mechanism for detecting positions arrived at via move transpositions. But as far as I know it's only used to save time in re-evaluating positions that have already been detected.

In order to use the information available in the hash table for search tree pruning, the hash table structure would have to be modified to provide a pointer to the search tree node associated with the position so that the subsequent moves in that line can be identified. That's pretty straightforward.

But the results may not be directly usable and, if they are, they are likely not going to be as accurate. Any time a position is reached that's in the hash table, that position will likely have occurred at a higher move/ply number. As a result, expansion of the search tree from that point, if the same expansion is used from the ply that the position was initially detected, will not be as deep as if the search tree were expanded with the duplicate position just detected as the root of the search tree. This may or may not be significant depending on the position and probably many other factors.

Besides, because of the chess engines' non-determinism, there is no guarantee that the subtree expanded from the second detected occurrence of the position will be the same as the subtree expanded from original position. And who's to say whether the original or subsequent search tree(s) will be better at identifying the variation developed from the root of that subtree?

Still, even if the expansion of the subtree originating from subsequent detections of the same position, the time savings will likely allow the search tree to be expanded to a deeper depth, possibly improving the accuracy of detecting the principal variation.

Given these conditions, and I suspect that there are others, I have no idea whether making use of the hash table for search tree pruning would increase or decrease the accuracy of the principal variation, nor do I know if it has ever been attempted. I would think that in order to determine its effectiveness that a series of games could be conducted between two versions of the engine, one using the hash table as a means of search tree pruning and one not using it. But, for all I know, this might have already been tried and discarded because it either didn't result in an overall improvement or detriment in the engines' playing.