In other words, each item in those arrays is an integer and its index on an array is mapped to a unique position. Thus so far none of popular EGTBs store any extra information and their records actually contain those integers only.Īll records of an endgame are simply organized as two arrays (one array for one side/color). However, due to large numbers of involving positions, any additional information may make the whole EGTB becomes significantly larger. Theoretically, we can add more information to each position’s record. To answer the 3rd question, the best move of a position can be indirectly calculated: generate all legal moves, make them, probe all new positions, compare probing scores for the highest one and the associated move is the best one. Typically each position's record associates with an integer number which informs how far that position is from mating/being mated or converting (depends on the type of its metrics).īased on values of those integer numbers it can answer directly two questions of the EGTB: 1) for a given position it is a draw or a win/loss position and 2) how far it is from mating/being mated or converting. All involving positions in an endgame must have the same material. Each endgame is a set of records about positions’ information. Their data typically are too large for downloading and storingĪn EGTB is a set of endgames.
#Endgame tablebase 7 pieces code
Engines don’t need to have the knowledge and code about those endgames.Moves are the perfect ones, leading the shortest line to win.Engines don’t have to search but retrieves data thus they can move instantly.How far/how many move from matting/being mated.
It is a kind of a dictionary of all endgame positions which can answer immediately for a given position: Both human and chess engines may miss badly the chances if they don’t know or not good enough about the endgame they are playing.Īn EGTB can help to solve this period. Sometimes the winning side may lose the change since the rule 50 moves and/or making blunders. Even the game can finish in this way but it is not in a perfect way: it takes time to compute moves, may use more moves than necessary. Both human/chess engines can finish the endgame by continuing searching, applying some endgame rules. When a chess game goes to the endgame phase, it may complete soon with the result as a draw or a win/loss. The term Tablebase opposed to endgame database was coined by Steven Edwards by means of a data vector and a single file access for both sides to move, when he introduced his Edwards' Tablebases, addressing several shortcomings of Ken Thompson's earlier database of positions with the weaker and hence potentially losing side to move only. Positions with non-null castling rights could be represented in an EGTB but typically are not. What all different formats of tablebases have in common is that every possible piece placement has its own, unique index number which represents the position where the information about the position is located in the file. The tables are usually divided into separate files for each material configuration and side to move. During its game play and/or search, recognizing a specific material composition, a chess program can probe, or in principle compute these tables to determine the outcome of positions definitively and act as an oracle providing the optimal moves. Precalculated endgame tables generated by an exhaustive retrograde analysis.
0 kommentar(er)
