I wonder if you tried to use move order that is not based on history(it means of course not using killer moves and not using hash for order of moves and caring to have move generator that always order the moves in the same order so you cannot use a piece list that has not constant order)Tord Romstad wrote:No. My move generation test contains of 500 randomly selected positions from my program's games. I disable LMR, loop through all the positions, search every position to a depth of 12 plies, and compute various statistics (total number of nodes, the arithmetic and geometric mean of the number of nodes per position, average effective branching factor, and so on).bob wrote:Are you searching tactical positions?Tord Romstad wrote:
- For the non-capturing moves after the hash move and killers, history move ordering performs better than no move ordering, as expected. But trying to refine this by using SEE values does not work. I have tried to sort the moves into two groups, first searching non-captures with SEE value zero ordered by history scores, and then searching losing non-captures by their SEE values. This performs slightly worse than simplistic history move ordering for all moves. I have no idea why.
- Searching the losing captures after the non-captures is slightly better than searching them before the non-captures. This is not entirely unexpected, but intuitively I would expect that searching the losing non-captures after the losing captures (i.e. first the hash move, then winning and equal captures, then killers, then non-losing non-captures, then losing captures, and finally losing non-captures) would perform better still. Surprisingly, this is not the case.
Why? Keep in mind that we are only talking about moves with negative SEE value here. As an example, consider the following position fragment:If so, losing captures before non-captures would make sense. Otherwise, to me, it does not at all.
[D]8/6p1/7b/7R/8/8/8/8 w - -
Why should Rg5 be searched before Rxh6? Wouldn't you expect the second move to have a much higher probability of being the best move? Still, my tests indicate that searching the losing captures after the losing non-capture performs slightly better. I wish I understood why...
Tord
I think that it may be interesting to know if even in these conditions searching the non-capture perform slightly better and if not what is the reason that it is changed when you improve your order of moves.
Is it hash or killers?
Uri