25,161
edits
Changes
no edit summary
=Data=
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.
Based on values those integer numbers can answer directly two purposes questions of the EGTB: for a given position it is a draw or a win/loss position and how far it is from mating/being mated or converting. From those numbers, the best move of a position can be indirectly calculated as below part mentions. Theoretically, we can add more information to each item. However, due to large involving positions, any additional information may make the whole EGTB becomes significantly larger. None of the popular EGTBs store any extra information for each item.
All records of an endgame are simply organized as two arrays (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. For a given chess position, we will calculate its index then access its data record/integer via that index without searching.
==Endgame files==
Those arrays of an endgame can be stored in files. Typically each array is stored in one file. However, sometimes they can be combined into one larger file or splitted into more files to easier copy or manage. Those files may be in the form of none or compressed. If they are compressed, they are typically divided and compressed by small blocks thus they don't need to load and decompress all data to extract just a position.
==In memory==
Some chess engines create themselves EGTBs on-flight and keep all data in memory without saving/loading to files. Due to limit by initial time they can generate and use very small EGTBs only.
==Sizes==
The size of an endgame depends on:
* The number of involving pieces: more pieces, the bigger size
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 and has below steps:
* convert a given chess position into an index via indexing algorithms
* access data (typically organized organised as an integer arrayarrays of integers) using the index to retrieve the integer of that chess position
If data of that endgame is not ready in memory, usually the probe process has to do some extra work:
* From data index calculate to the block index
* Read data of that block from storage into memory
* Uncompress the block data (if it is compressed)* Convert the endgame index into block index and retrieve the right needed data
==Search==
==Speed==
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.
=Brief Info=
* [http://www.talkchess.com/forum3/viewtopic.php?f=7&t=73481 Using Freeware AI and Dynamically Generated Endgame Tablebases] by Steve Schooler, [[CCC]], March 27, 2020
* [http://www.talkchess.com/forum3/viewtopic.php?f=7&t=73598 Almost perfect DTM tablebase] by [[Dann Corbit]], [[CCC]], April 08, 2020
* [http://www.talkchess.com/forum3/viewtopic.php?f=7&t=76089 Asynchronous tablebase lookups] by [[Steinar H. Gunderson|Sesse]], [[CCC]], December 17, 2020 <ref>[https://kernel.dk/io_uring.pdf?source=techstories.org io_uring.pdf]</ref>'''2021'''* [http://www.talkchess.com/forum3/viewtopic.php?f=7&t=76089 Asynchronous tablebase lookups76659 Stalemate Tablebases] by [[Steinar H. Gunderson|Sesse]]Dries De Clercq, [[CCC]], December 17February 21, 2020 <ref>2021 » [[https://kernel.dk/io_uring.pdf?source=techstories.org io_uring.pdfStalemate]]</ref>
=External Links=
