Question about the meaning of input shape and output shape

[tianyu-z]

The input shape plane is (batch_size, 112, 8, 8) and the output shape is (batch_size, 1858). What is the meaning of 112 and the 1858? In other words, what should I input to the model and what I should expect the model to output? Thank you!

update the answer from the chat:

About the input

Input planes are encoded using this function https://github.com/LeelaChessZero/lc0/blob/master/src/neural/encoder.cc#L134 It's quite complicated, but recent networks use the INPUT_CLASSICAL_112_PLANE encoding which is simple, and it's also the same encoding that AlphaZero used -- you may check AlphaZero paper.

Different from AZ paper (https://arxiv.org/pdf/1712.01815.pdf, page 13), their total number of input channels seems to be 119 rather than 112. In lc0, the "repetitions" is set to be 1 and there is one more feature which is all one to help conv to detect edge.

(6+6+1)x8+1+1+2+2+1 +1=112 which is (P1 piece + P2 piece + Repetition)*history_len + Colour + Total move count + P1 castling + P2 castling + No-progress count + [one more feature which is all one to help conv to detect edge]

Board Representation:

N × N × (MT + L) Image Stack: The state of the game is represented by a three-dimensional array, where: N × N represents the chessboard dimensions (8x8 for chess). T = 8. MT + L refers to the depth of the stack, with different layers representing various game features.

T Sets of M Planes:

These sets represent the game state at different time-steps, providing the network with a history of the game. Each set contains M planes, with each plane being an N × N grid.

Binary Feature Planes:

These planes indicate the presence of each player's pieces on the board. For example, there could be separate planes for the player's pawns, knights, bishops, etc., and similar planes for the opponent's pieces.

Board Orientation:

The board is oriented from the perspective of the current player, meaning the network always 'sees' the board as if it were making the next move.

Additional Features:

L Constant-valued Input Planes: These planes provide additional contextual information about the game: Player's Color: Which player (white or black) the neural network is analyzing the position for. Total Move Count: The number of moves made in the game so far. Special Rules: Information about game-specific rules, such as castling rights in chess, repetition counts, and no-progress counts.

Chess-Specific Implementation:

From Table S1, we can see how these features are quantified for chess:

P1 piece and P2 piece (6 each): Indicates the presence of each type of piece (pawn, knight, bishop, rook, queen, king) for both players. Repetitions (2): Tracks the repetition of positions, important for threefold repetition rules. Other Features (7 in total): Includes color, total move count, castling rights for both players (kingside and queenside separately), and no-progress count.

About the output

output[0]

https://github.com/LeelaChessZero/lc0/blob/master/src/chess/bitboard.cc#L36

Basic Moves: The majority of these moves are in the format 'e2e4', 'd7d5', etc. This is standard algebraic notation, where the first two characters represent the starting square (file and rank) and the next two characters represent the ending square. For example, 'e2e4' means moving a piece from square e2 to e4.

Promotions: Towards the end of the list, there are moves like 'a7a8q', 'b7b8r', etc. These represent pawn promotion moves. In chess, when a pawn reaches the opposite end of the board, it must be promoted to a queen, rook, bishop, or knight. In these notations, the first four characters denote the move (e.g., a pawn moving from a7 to a8), and the fifth character denotes the piece the pawn is promoted to ('q' for queen, 'r' for rook, 'b' for bishop, and 'n' for knight).

output[1] and output[0]

there are two additional ones, the "value" typically (batch_size, 3) which is the win, draw, loss probabilities for the current position and the optional "moves left" which is (batch_size, 1) giving an estimate of the moves left in the game.

[mooskagh]

Closing as it was discussed in the chat.

[Dboingue]

chat not being shared. bummer. I learn much from discussions.. It looked like a good starter here, going for the jugular of chess interpretable information. Not that I am sure to understand where that is meant to go, but at least I enjoyed the structuring of the starting post. Sounds like good language for user documentation. Not that I would be working for that. just saying.. Sounds like well informed yet clarifying notions to share outside of GitHub and chats.

I notice trying to bring information sharing at the level of the A0 papers which did not have any source code to use toward supporting higher level models of what they were doing. I thought I understood the framework from those papers, but I have not been able to follow up further in my long past attempts at figuring out what LC0 might be doing. I may have missed some documentation evolution as well.

I might have my own topics of difficulty being factors, but then I see this, and I say, finally, someone with the same wanting to get a perspective from chess world, in quantifiable language, yet not fully tangles with the coding level.