Changes

===With a list of legal moves=== If the [[Move Generation|generated moves ]] inside a [[Move List|move list]] are [https://en.wikipedia.org/wiki/Determinism deterministic], one may encode moves as relative list index. Since the maximum number of moves per positions seems 218 <ref>[https://www.stmintz.com/ccc/index.php?id=424966 Subject: Maximum Number of Legal Moves] by [[Andrew Shapira]], [[CCC]], May 08, 2005</ref> <ref>[http://www.talkchess.com/forum/viewtopic.php?t=39332 max amount of moves from a position?] by [[Srdja Matovic]], [[CCC]], June 10, 2011</ref> , one [[Byte|byte]] is enough to index the move. This encoding was used in early game databases.

==Move Enumeration=Encoding moves as if on an empty board= ===Per Square=== For the subset of common chess positions a faster encoding scheme is possible that doesn't require move generation of any kind.  Let's enumerate the upper bound on the number of unique moves Moves a piece Piece of a given type can make on an empty boardfrom one [[Squares|Square]] - for [[Sliding Pieces|sliding pieces]] assuming no obstacles:* pawn {| class="wikitable"! Piece! # of Moves! Remarks|-| [[Pawn]]| style="text- align:right;" | 12 (| 7th rank, 4 promotion [[Promotions|promotions]] * 3 targets)[[Target Square|target squares]]* knight |-| [[Knight]]| style="text- align:right;" | 8* bishop | from the 16 [[Center#ExtendedCenter|extended center]] squares|-| [[Bishop]]| style="text- align:right;" | 13* rook | from the 4 [[Center|center]] squares|-| [[Rook]]| style="text- align:right;" | 14* queen | from any square|-| [[Queen]]| style="text- align:right;" | 27* king | from the 4 [[Center|center]] squares|-| [[King]]| style="text- align:right;" | 8 (| there are two additional [[Castling|castling moves]], <br/>but they are only possible from the start position <br/>where the king has 5 normal moves available.)|}

So for legal [[Chess960 ]] positions with at most 3 queens on the board one can encode any legal move in just one byte. Note that whether the result can always fit in one byte is determined based solely one the position, so no additional information needs to be stored for disambiguation. This way it's easy to implement a fallback for the positions not supported by this encoding (this could be either to use 2 bytes for the move index or use legal move generation to ensure all values take one byte).One way to encode a position using this information is in the following way:

Alternatively we can go through each piece type in some order (instead of going through individual squares), which allows faster computation of the offset if <code>[[Population Count|popcount</code> ]] instruction is available:

To decode the move we step through different offsets in the same way as we did when encoding, but now we have to look for the range of values that contains the encoded move index - once we find the range we can just decode the move index of that specific piece type (using an inverse of <code>piece_move_index</code>). While this method allows much faster encoding/decoding then the one involving a list of legal moves, it requires additional work if one needs to verify the correctness of the decoded moves (in the former one just needs to check if the index is within bounds).

While this method allows much faster encoding/decoding then the one involving a list of legal moves, it requires additional work if one needs to verify the correctness of the decoded moves (in the former one just needs to check if the index is within bounds). This method is used in one of the move encodings available in the [[BCGN ]] chess game storage format<ref>[https://github.com/Sopel97/chess_pos_db/blob/master/docs/bcgn/move_index.md A detailed walkthrough of an implementation of BCGN's move index based move encoding scheme · GitHub]</ref>.

==Move Enumeration=Over All Squares===

==='''Pawn Moves=== '''

==='''Piece Moves=== '''

==='''All Moves=== '''