Move+Ordering

toc
 * Home * Search * Move Ordering**

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 move 
 * PV-Move from the principal variation of the previous Iteration
 * Hash Move - stored move from Transposition Table, if available
 * Internal Iterative Deepening - if no hash move is available, likely only at PV-Nodes

Captures
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
 * Static Exchange Evaluation abbreviated as **SEE**

Non-Captures

 * Killer Heuristic
 * History Heuristic
 * Relative History Heuristic
 * Dedicated Piece-Square Tables only for move ordering

Less common techniques
These techniques are well known theoretically for non-captures, but not all programmers use them:
 * Mate Killers
 * Countermove Heuristic
 * Guard Heuristic
 * Last Best Reply
 * Butterfly Heuristic
 * Threat Move from null move refutations
 * Enhanced Transposition Cutoff (ETC)
 * Refutation Table

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.
 * Chessmaps Heuristic
 * Neural MoveMap Heuristic

=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:
 * 1) PV-move of the principal variation from the previous iteration of an iterative deepening framework for the leftmost path, often implicitly done by 2.
 * 2) Hash move from hash tables
 * 3) Winning captures/promotions
 * 4) Equal captures/promotions
 * 5) Killer moves (non capture), often with mate killers first
 * 6) Non-captures sorted by history heuristic and that like
 * 7) Losing captures (* but see below


 * ) 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 inspired by Jos Uiterwijk's Countermove Heuristic article, based on the soundness of following rule of thumb, 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.
 * //The longer it takes to refute a move, the higher is its chance to become best move in the next iteration// ||

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.

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
 * Fixafan
 * Move Generation
 * Move List
 * Node Types
 * Odd-Even Effect
 * Search Explosion

=Publications=

1977 ...

 * Selim Akl, Monroe Newborn (**1977**). //The Principal Continuation and the Killer Heuristic//.1977 ACM Annual Conference Proceedings
 * Ozalp Babaoglu (**1977**). //Hardware implementation of the legal move generation and relative ordering functions for the game of chess//. Master's thesis, University of California, Berkeley

1980 ...

 * Jonathan Schaeffer (**1983**). //The History Heuristic//. ICCA Journal, Vol. 6, No. 3
 * Prakash Bettadapur (**1986**). //Influence of Ordering on Capture Search//. ICCA Journal, Vol. 9, No. 4
 * Dap Hartmann (**1988**). //Butterfly Boards//. ICCA Journal, Vol. 11, Nos. 2/3

1990 ...

 * Dap Hartmann, Peter Kouwenhoven (**1991**). //Sundry Computer Chess Topics//. Advances in Computer Chess 6
 * Jos Uiterwijk (**1992**). //The Countermove Heuristic//. ICCA Journal, Vol. 15, No. 1
 * Jos Uiterwijk (**1992**). //Memory Efficiency in some Heuristics//. ICCA Journal, Vol. 15, No. 2
 * Ingo Althöfer (**1992**). //Move Ordering by Time Ordering//. Correspondence, ICCA Journal, Vol. 15, No. 2
 * Eric Thé (**1992**). //[|An analysis of move ordering on the efficiency of alpha-beta search]//. Master's thesis, McGill University, advisor Monroe Newborn » Fixafan
 * Yi-Fan Ke, Tai-Ming Parng (**1993**). //The Guard Heuristic: Legal Move Ordering with Forward Game-Tree Pruning//. ICCA Journal, Vol. 16, No. 2
 * Mei-En Chen, Yo-Ping Huang (**1995**). //[|Guard heuristic by dynamic fuzzy reasoning model for Chinese chess]//. Proceedings of ISUMA-NAFIPS '95
 * Kieran Greer, Piyush Ojha, David A. Bell (**1999**). //A Pattern-Oriented Approach to Move Ordering: the Chessmaps Heuristic//. ICCA Journal, Vol. 22, No. 1

2000 ...

 * Kieran Greer (**2000**). //[|Computer chess move-ordering schemes using move influence]//. [|Artificial Intelligence], Vol. 120, No. 2
 * Levente Kocsis, Jos Uiterwijk, Jaap van den Herik (**2001**). //Move Ordering using Neural Networks//. IEA/AIE 2001, [|LNCS] 2070
 * Levente Kocsis, Jos Uiterwijk, Eric Postma, Jaap van den Herik (**2002**). //[|The Neural MoveMap Heuristic in Chess]//. CG 2002
 * Yoshinori Higashiuchi, Reijer Grimbergen (**2005**). //Enhancing Search Efficiency by Using Move Categorization Based on Game Progress in Amazons//. [|pdf]
 * Mark Winands, Erik van der Werf, Jaap van den Herik, Jos Uiterwijk (**2006**). //The Relative History Heuristic//. CG 2004, [|pdf]
 * Jeff Rollason (**2006**). //[|Driving search with Plausibility analysis: Looking at the right moves]//. AI Factory, Winter 2006
 * Jeff Rollason (**2007**). //[|Negative Plausibility]//. AI Factory, Spring 2007 » Relative History Heuristic
 * Rémi Coulom (**2007**). //[|Computing Elo Ratings of Move Patterns in the Game of Go]//. ICGA Journal, Vol. 30, No. 4, CGW 2007, [|pdf]
 * Timothy Furtak, Michael Buro (**2009**). //Minimum Proof Graphs and Fastest-Cut-First Search Heuristics//. IJCAI 2009, [|pdf]

2010 ...

 * David J. Wu (**2011**). //Move Ranking and Evaluation in the Game of Arimaa//. B.Sc. thesis, [|Harvard College], [|Cambridge, Massachusetts], [|pdf] » Arimaa
 * David J. Wu (**2015**). //Designing a Winning Arimaa Program//. ICGA Journal, Vol. 38, No. 1

=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
 * [|Pawn Structure "Holes" and Move Ordering] by Daniel A. Thies, rgcc, February 12, 1996 » Pawn Structure, Holes
 * [|computer chess "oracle" ideas...] by Robert Hyatt, rgcc, April 1, 1997
 * [|Measure of moveorder quality] by Ralf Elvsén, CCC, September 04, 1999
 * [|Fast way to sort moves in movelist ?] by Stefan Plenkner, CCC, October 14, 1999

2000 ...

 * [|Move ordering?] by Severi Salminen, CCC, April 28, 2000
 * [|Better subject title: Move ordering] by Tom Kerrigan, CCC. May 31, 2000
 * [|Move ordering ideas] by Matt McKnight, CCC, March 08, 2001
 * [|Dynamic move ordering for capture/promotions?] by Scott Gasch, CCC, April 02, 2001
 * [|root search ordening] by Jan Willem de Kort, CCC, May 02, 2001
 * [|Move ordering at root of search] by Tom King, CCC, May 07, 2001
 * [|A SIMD idea, eg. Piece/Gain of a capture target] by Gerd Isenberg, CCC, January 21, 2004 » SSE2
 * [|move ordering and node count] by Martin Fierz, CCC, March 29, 2004
 * [|Move ordering at root] by Renze Steenhuisen, CCC, April 04, 2004
 * [|Fail-high on first move stat (86%)] by Michael Henderson, CCC, July 29, 2004 » Fail-High

2005 ...
> [|Re: Move ordering: Delaying moves on the history phase] by Lance Perkins, CCC, May 14, 2008
 * [|Move ordering at different (Knuth) node types] by Tom Likens, Winboard Forum, February 21, 2006 » Node Types
 * [|SEE on non-capture moves in main search] by Gary, CCC, March 28, 2007 » Static Exchange Evaluation
 * [|caps->noncaps vs. goodcaps->noncaps->badcaps] by James Swafford, CCC, July 18, 2007
 * [| Move ordering: Delaying moves on the history phase] by Miguel A. Ballicora, CCC, May 13, 2008
 * [|Order of implementing things] by cyberfish, CCC, October 10, 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
 * 2014**
 * [|Idea of different history] by Daniel José Queraltó, CCC, April 14, 2014 » History Heuristic
 * [|Effectiveness of killer moves] by Alex Ferguson, CCC, August 17, 2014
 * [|Solving a fail low situation at the root] by Alberto Sanjuan, CCC, November 03, 2014 » Aspiration Windows, Fail-Low, Root

2015 ...

 * [|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
 * 2018**
 * [|Simple quiet move sorting] by Andrew Grant, CCC, January 13, 2018
 * [|[Discussion - Measuring move ordering]] by Ed Schroder, CCC, February 24, 2018

=External Links= > media type="custom" key="25442170"
 * [|Move Ordering in Rebel] by Ed Schröder
 * Hiromi Uehara, [|The Trio Project], feat. Anthony Jackson & Simon Phillips - Move, (2012), [|YouTube] Video

=References= =What links here?= include page="Move Ordering" component="backlinks" limit="300"
 * Up one level**