Changes

When a [[Chess Game|chess game]] goes to the [[Endgame|endgame]] phase, it may complete soon with the result as a draw or a win/loss. Both human/chess engines can finish the endgame by continuing searching, applying some endgame rules. The game can finish in this way but it is not in a perfect way: it takes much time to make move, use more moves than necessary. Sometimes the winning side may lose the change since the rule 50 moves. 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.

An EGTB can help to solve this period. It is a kind of a dictionary of all endgame positions which can answer directly or indirectly immediately for a given position:* If it is a draw or a win/loss* how How far/how many move from matting/being mated* what What is the best move

* It does not Engines don’t have search but retrieves data thus it they can move instantly

* Data Their data typically are too large for downloading and storing* They may slow down the search* Require complicated code codes for probing

An EGTB is a set of endgames. Each endgame is a set of records about positions’ information. All involving positions (they in an endgame must have the same material). Each position 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). All numbers of an endgame are simply organized as two arrays of integers (one array for one side/color). In other words, each item in those arrays is an integer and its index on an array is mapped to a unique position.

Those arrays Based on values those integer numbers can answer directly two questions of an endgame can be stored in files. Popularly each array the EGTB: for a given position it is a draw or a win/loss position and how far it is stored in one file. But sometimes they can be combined into one file. Those files may be in the form of none from mating/being mated or compressedconverting. If they are compressedFrom those numbers, they are divided and compressed by small blocks thus they don't need to decompress all to extract data the best move of few positionsa position can be indirectly calculated as below part mentions.

When a chess program (e.g., a chess engine or a chess GUI) works with an EGTB, it needs to retrieve data (integer numbers) for some given chess positions. The process named probe. It is not a search but retrieve data which and has below steps:

* access data (typically organized organised as an integer arrayarrays of integers) using the index to retrieve the integer of that chess position

* From data index calculate to the block index

* Uncompress the block data (if it is compressed)* Convert the endgame index into block index and retrieve the right needed data

Typically the probe process requires some computing and it may access storage and decompress which is usually so slow, compared with one stored in memory. All may make it be a slow one. An engine that probes EGTB when searching may make the whole search be slower. Sometimes the benefit from probing EGTBs maybe not enough to cover the loss of slower search. That’s why the probing should be planned and implemented carefully. EGTB files may have to store in fast storage and/or using some huge systems’ caches. The good point is that the engine can stop searching on the branch probed the EGTB. 

* [[Ulrich Thiemonds]] ('''1999'''). ''Ein regelbasiertes Spielprogramm für Schachendspiele''. [https://en.wikipedia.org/wiki/University_of_Bonn University of Bonn], Diploma Diplom thesis, [httphttps://www.iaiidb.uni-bonn.de/~idbpublications/diplomarbeitenda/thiemonds99.psda_thiemonds_1999.gz zipped pspdf pdf] (German)

* [https://www.chessdb.cn/queryc_en/ Chess Cloud Database Query Interface] by [[Bojun Guo|noobpwnftw]] [[Syzygy Bases|Syzygy]] DTZ50 probing