Move ordering based on stored values of child nodes

[Morten Lohne]

So I've been trying to read up on move ordering for my chess engine. Checking the position in the hash table, and searching the "hash move" first, seems to be a universal technique. Is it possible to also look up every child node in the table, get their values from shallower searches, and then sort the entire move vector based on that? It seems like a natural next step, but for some reason I can't find anyone else who has tried it. Is it just a bad idea for some reason I don't understand? How else are top engines able to check the best move first 90% of the time?

[hgm]

The problem is that for >99% of all nodes the score is not known at all, not even from a shallower search. All that is known is an upper or lower bound on the score. So what you would get when you retrieve all scores for the daughter nodes from the previous iteration, is something like this:

hash move: +0.76 (exact)
10 other moves +0.76 (upper bound)
8 other moves: +0.75 (upper bound)
6 other moves +0.73 (upper bounds)
remaining moves +0.70, +0.53, 0.0, -2.13, -200.0 (all upper bounds)

The second-best move could easily be the one with upper bound +0.70. How would you know?

Engines get the best move first >90% of the time because the hash move happens to be best move >90% of the time.

[Evert]

With current move ordering heuristics, you get a cut-off from the first three moves in 95-99% of cases. That's the statistic you have to beat.
Any effort spent on move ordering in ALL-nodes is wasted.
Any effort in improving move ordering in a CUT-node is wasted in 95-99% of cases, so whatever you propose needs to be fast. Getting statistics for all moves is not cheap (especially not in horizon nodes).
Not to forget: move ordering doesn't need to be perfect. It needs to be good enough.

[Daniel Shawul]

So I've been trying to read up on move ordering for my chess engine. Checking the position in the hash table, and searching the "hash move" first, seems to be a universal technique. Is it possible to also look up every child node in the table, get their values from shallower searches, and then sort the entire move vector based on that? It seems like a natural next step, but for some reason I can't find anyone else who has tried it. Is it just a bad idea for some reason I don't understand? How else are top engines able to check the best move first 90% of the time?

I do this in alpha-beta rollouts since I have the tree stored in memory. You can do things like sorting by size of subtree similar do what alpha-beta engines do at the root. I belive it gives better move ordering overall.

[Cardoso]

With current move ordering heuristics, you get a cut-off from the first three moves in 95-99% of cases. That's the statistic you have to beat.

Do you get that consistently throughout the entire game?
Do you get that for example from the starting position or after the first say 10 moves?
And what about when your engine is behind or even loosing?
And what happens when the engine changes it's mind often?