For captures (if any), a simple, but quite efficient heuristic is (re)capturing the last moved piece with the least valuable attacker. Otherwise following heuristics may used, concerning the order of captures:
MVV-LVA - Most Valuable Victim - Least Valuable Aggressor
After move generation with assigned move-scores, chess programs usually don't sort the whole move list, but perform a selection sort each time a move is fetched. Exceptions are the Root and further PV-Nodes with some distance to the horizon, where one may apply additional effort to score and sort moves. For performance reasons, a lot of programs try to save the move generation of captures or non-captures at expected Cut-Nodes, but try the hash-move or killer first, if they are proved legal in this position.
*) Depending on the implementation, the board representation, whether and where SEE is used, the extension policy (recapture extensions) and other stuff - many programmers favor losing captures before other none-captures - directly behind the killers. They are kind of forced, and one possibly has to deal with all kind of tactical motives and interactions, one may not consider in move ordering. Such as pins, batteries, discovered attacks and overloaded defenders. Otherwise, obviously losing captures are likely refuted cheaply. But if a losing capture fails high for some reason, we have saved the effort to generate, and more importantly to search other non-captures at all.
Node Type Considerations
Move ordering and scoring effort might be controlled by expected Node Types.
PV-nodes
At PV-nodes move ordering is very important, since the best alpha-increase as early as possible makes further search cheaper, due to narrower windows in Alpha-Beta, while in PVS later but better moves require re-searches of the null windowscout.
Cut-nodes
Move ordering is crucial at expected and confirmed Cut-nodes, since it is important to fail-high as early as possible, as best with the first move, as in greater than 90% of all fail-high nodes. However, in situations where multiple moves may cut, e.g. with huge material advantage, we like it as cheap as possible, but not necessarily a huge subtree with f.i. due to check extensions.
All-nodes
At confirmed ALL-nodes with null windows, move ordering didn't care that much. Since we don't know in advance (otherwise we wouldn't search at all), and expected All-nodes may become Cut-nodes, move ordering is an issue as well, but usually with less effort for late moves.
Depth and Ply Considerations
Move ordering effort might be controlled by considering draft and/or plies from root. The closer the root, the farther the horizon, the more effort might be justified to score and sort moves.
Root Node Considerations
Despite trying the best move and principal variation from previous iteration first, iterative deepening offers another ressource to order the remaining moves at the root - their subtree size which could be easily determined. As already mentioned by Ingo Althöfer in an 1992 ICCA Journal correspondence [9] inspired by Jos Uiterwijk'sCountermove Heuristic article [10], based on the soundness of following rule of thumb,
The longer it takes to refute a move, the higher is its chance to become best move in the next iteration
the old idea is to use the search time or subtree size of the depth-n iteration to reorder the direct successors of the root before the depth-(n+1) iteration. Some programs use the evaluation to initially score the moves, to adjust them by their subtree size in subsequent iterations.
In the quiescence search, captures are often approximated, for speed. For example, PxQ need not have a SEE performed on it, since it is clearly a winning capture, where RxB might have the SEE done, to see if it is a winning or possibly losing capture if the bishop is protected.
Table of Contents
For the alpha-beta algorithm to perform well, the best moves need to be searched first. This is especially true for PV-nodes and expected Cut-nodes. The goal is to become close to the minimal tree. On the other hand - at Cut-nodes - the best move is not always the cheapest refutation, see for instance enhanced transposition cutoff. Most important inside an iterative deepening framework is to try the principal variation of the previous iteration as the leftmost path for the next iteration, which might be applied by an explicit triangular PV-table or implicit by the transposition table.
Standard techniques
Following techniques are common in finding a good first moveCaptures
For captures (if any), a simple, but quite efficient heuristic is (re)capturing the last moved piece with the least valuable attacker. Otherwise following heuristics may used, concerning the order of captures:Non-Captures
Less common techniques
These techniques are well known theoretically for non-captures, but not all programmers use them:Using Neural Networks
Move ordering (as well as Time Management) is an interesting application of Neural Networks, as introduced by Kieran Greer et al. and Levente Kocsis et al.Typical move ordering
After move generation with assigned move-scores, chess programs usually don't sort the whole move list, but perform a selection sort each time a move is fetched. Exceptions are the Root and further PV-Nodes with some distance to the horizon, where one may apply additional effort to score and sort moves. For performance reasons, a lot of programs try to save the move generation of captures or non-captures at expected Cut-Nodes, but try the hash-move or killer first, if they are proved legal in this position.A typical move ordering consists as follows:
*) Depending on the implementation, the board representation, whether and where SEE is used, the extension policy (recapture extensions) and other stuff - many programmers favor losing captures before other none-captures - directly behind the killers. They are kind of forced, and one possibly has to deal with all kind of tactical motives and interactions, one may not consider in move ordering. Such as pins, batteries, discovered attacks and overloaded defenders. Otherwise, obviously losing captures are likely refuted cheaply. But if a losing capture fails high for some reason, we have saved the effort to generate, and more importantly to search other non-captures at all.
Node Type Considerations
Move ordering and scoring effort might be controlled by expected Node Types.PV-nodes
At PV-nodes move ordering is very important, since the best alpha-increase as early as possible makes further search cheaper, due to narrower windows in Alpha-Beta, while in PVS later but better moves require re-searches of the null window scout.Cut-nodes
Move ordering is crucial at expected and confirmed Cut-nodes, since it is important to fail-high as early as possible, as best with the first move, as in greater than 90% of all fail-high nodes. However, in situations where multiple moves may cut, e.g. with huge material advantage, we like it as cheap as possible, but not necessarily a huge subtree with f.i. due to check extensions.All-nodes
At confirmed ALL-nodes with null windows, move ordering didn't care that much. Since we don't know in advance (otherwise we wouldn't search at all), and expected All-nodes may become Cut-nodes, move ordering is an issue as well, but usually with less effort for late moves.Depth and Ply Considerations
Move ordering effort might be controlled by considering draft and/or plies from root. The closer the root, the farther the horizon, the more effort might be justified to score and sort moves.Root Node Considerations
Despite trying the best move and principal variation from previous iteration first, iterative deepening offers another ressource to order the remaining moves at the root - their subtree size which could be easily determined. As already mentioned by Ingo Althöfer in an 1992 ICCA Journal correspondence [9] inspired by Jos Uiterwijk's Countermove Heuristic article [10], based on the soundness of following rule of thumb,An idea to apply randomness and/or bonuses, i.e. developing bonus, or penalties to move scores at the root by an oracle approach, was proposed by Ronald de Man - without any changes in alpha-beta search or leaf evaluation, and without any problems with the transposition table [11] [12].
Ordering in Quiescence
In the quiescence search, captures are often approximated, for speed. For example, PxQ need not have a SEE performed on it, since it is clearly a winning capture, where RxB might have the SEE done, to see if it is a winning or possibly losing capture if the bishop is protected.See also
Number of Leaf Nodes
Publications
1977 ...
1980 ...
1990 ...
2000 ...
2010 ...
Forum Posts
1996 ...
Re: computer chess "oracle" ideas... by Ronald de Man, rgcc, April 3, 1997
Re: computer chess "oracle" ideas... by Ronald de Man, rgcc, April 7, 1997
2000 ...
2005 ...
Re: Move ordering: Delaying moves on the history phase by Lance Perkins, CCC, May 14, 2008
2010 ...
- root move ordering by Edward Yu, CCC, June 02, 2010
- Move ordering improvements by Howard E, Open Chess Programming Forum, September 26, 2010
2011- out of check move ordering by Don Dailey, CCC, March 12, 2011 » Check
- The LBR move ordering heuristic by Steven Edwards, CCC, March 26, 2011 » Last Best Reply
- Move ordering by PST by Onno Garms, CCC, April 16, 2011 » Piece-Square Tables, History Heuristic, Onno
- Move ordering question by Stef Luijten, CCC, June 11, 2011
- Root node search in Stockfish by Onno Garms, CCC, June 12, 2011 » Stockfish, Root
- Improve Move Ordering for Alpha Beta by Thomas Petzke, mACE Chess, August 11, 2011
2012- Minimax/ Alpha beta pruning Move Ordering? by Felix, Stack Overflow, January 18, 2012
- Move ordering idea (old and new?) by Daniel Homan, CCC, Aug 09, 2012 » Countermove Heuristic
- How effective is move ordering from TT? by Bill Henry, CCC, August 09, 2012 » Transposition Table
- Relationship between move ordering and pruning by Don Dailey, OpenChess Forum, December 17, 2012 » Pruning
- Move Ordering? by Thomas Kolarik, CCC, December 28, 2012
2013- Killer and History: Increased Node Count by Cheney Nattress, CCC, January 15, 2013
- Root move order (again) by Alberto Sanjuan, CCC, March 21, 2013
- History pruning / move ordering question by Jerry Donald, CCC, May 10, 2013
- Move ordering contest by Ed Schroder, CCC, May 26, 2013
- An idea for move ordering at the root by Steven Edwards, CCC, June 09, 2013
- MoveOrdering++ by Henk van den Belt, CCC, August 16, 2013
- How do you get a "Best first move" near the leaves by Henk van den Belt, CCC, December 05, 2013
20142015 ...
- Idea #8430: Optimizing move ordering, very slowly by Steven Edwards, CCC, April 06, 2015
- Move ordering for cheapest refutation by Matthew Lai, CCC, August 09, 2015
- Bonus for "null move SEE" by Matthew Lai, CCC, August 23, 2015
- Q: Move ordering, checks by Harm Geert Muller, CCC, September 02, 2015
- Ordering of Root moves and search instability ! by Mahmoud Uthman, CCC, October 26, 2015 » Search Instability
2016- Sorting Captures by David Cimbalista, CCC, August 03, 2016
- New killer idea by Alexandru Mosoi, CCC, August 28, 2016
- Starting with move ordering by Luis Babboni, CCC, August 28, 2016
- Best move statistics by Matthew Lai, CCC, September 12, 2016
- Searching worse moves first by Matthew Lai, CCC, September 14, 2016
- move ordering especially ordering&searching of root move by Mahmoud Uthman, CCC, December 21, 2016
2017- Move ordering ? by Mahmoud Uthman, CCC, January 15, 2017
- Move ordering ? by Mahmoud Uthman, CCC, February 04, 2017
- Sorting losing captures ? by Mahmoud Uthman, CCC, February 25, 2017
- Move ordering statistics by Sander Maassen vd Brink, CCC, February 26, 2017
- speed up or avoiding move sorting by Alexandru Mosoi, CCC, March 19, 2017 » Zurichess
- Testing for Move Ordering Improvements by Cheney Nattress, CCC, March 25, 2017 » Engine Testing, Search Statistics
- Sorting algorithms by Fermin Serrano, CCC, April 22, 2017
- What is causing this problem? by Michael Sherwin, CCC, August 16, 2017 » RomiChess
- Ordering Capture Moves by Jason Fernandez, CCC, September 06, 2017 » Move Ordering - Captures
- Marginal hash move by Harm Geert Muller, CCC, September 16, 2017
- Unordered moves phenomenon by Alvaro Cardoso, CCC, October 03, 2017
- Move ordering by Matthew R. Brades, CCC, November 09, 2017
2018External Links
References
What links here?
Up one level