The title describes it all
Hads anyone tried to for example make the move ordering in krk (as example) based on statistics from e.g. 1000 krk endgames and find out that it is 90% rook move and 10% king move and then the move ordering will first try moves with the pieces with highest percentage.
Is this approach used anywher?
This is not likely to work, because 99.99% of the positions encountered in the search tree of an engine is totally unlike any position you would ever encounter in a game (or along the engine PV). So statistics derived from actual games in quite meaningless. The best move in 90% of the cases is to capture the fattest piece. As it is usually hanging. While in real games people would of course never leave pieces hanging.
To get an idea of what positions in search trees of engines like Houdini and Stockfish look like, imagine one player that is playing totally random moves, against an opponent that just passes his turn, biding his time while the random mover is wrecking his position, and occasionally, when the latter by sheer luck plays something that could become dangerous, executes the most valuable hostage put in harm's way.
I tried something like this not for the end but for the middle game. I created a data base about what quiet moves existed with what probability, what was their chance of producing a cutoff and what was the search effort behind them.
A move was not only classified by moving piece and target square but also by the most valuable piece it attacks after the move or whether it defends one of your own pieces. Even if you have all this information it is still very difficult to determine a least cost order of moves with it. Do you order a move with a high cut off probability but also high cost at the top of the list or at the end. I depends on the cost of the remaining moves in the list but those depend on the probability that those moves exist first.
I used an approximation to assign move order values to the moves in the list depending on their properties (cut off % and costs) and I got some reasonable tables. Did they help to cut down the tree size when I applied those order values to my quite moves (after hash, captures and killers).
No, they didn't. Ordering the moves just by moving piece (N, B, R ...) performed just as good (in fact even better because it was faster).
