EGTB Usage through GUI.

[ChessKnight]

As Toga-II and its derivatives uses scorpio bitbase, while Glaurung generates its own. But, is it possible that these both engine can use Nalimove EGTB through GUI like Arena?

[redpawn]

while Glaurung generates its own

Hi ChessKnight:

Could you tell me where I can find more about what Glaurung generates as end game tablebases.

Best Regards,

[h.g.muller]

If GUIs support tablebase probing (I do not know anything specifically about Arena, so I am talking hypothetically) they can do it only to bypass the engine in cases where the current board position is actually inside the tablebase. This is different from an engine using tablebases, as in the latter case the engine benifits already when the tabulated end-game positions become reachable in its search tree, so that it can actually plan to force a conversion into a won end-game position.

[ChessKnight]

H.G.Muller:

Thanks for reply.

Redpawn:

Could you tell me where I can find more about what Glaurung generates as end game tablebases.

Somewhere in this forum only there is a thread having this details.

[ChessKnight]

H.G.Muller:

If GUIs support tablebase probing (I do not know anything specifically about Arena, so I am talking hypothetically) they can do it only to bypass the engine in cases where the current board position is actually inside the tablebase.

Your thinking is in-line with the answer of Micheal of Arena. As per him, Arena can not probe Nalimov EGTB on behalf of non-compatible chess-engine.

Reason for asking this question is many chess-engines are capable of accessing an GUI opening book through GUI, which is a sort of database, EGTBs are also other form of database too!

Anyway your reply and feedback from Micheal reply my query completely. Thanx!

[h.g.muller]

Indeed from an implementation point of view a GUI opening book is exactly the same as a GUI tablebase. But due to the nature of the information they contain, the demands are different. With openings, you start in the book, and when you are out, you are out of it. There is no big advantage for engines to make concious attempts to get back into book once they are out, as the book would likely run out very quickly in other lines as well. If they accidentally get back into book by a move of their own choice, the book takes over again, but it is no big loss if they choose an independent line of play.

This is totally different for tablebases. There everything is decided by how you enter the tablebase, as the opponent will likely also use that tablebase. So stumbling into it randomly might really bungle a lot of games, and it payse very much to have the engine plan a path to a selected tablebase position. For opening books there is no similar "approach phase", as you start within the book. (If the book is any good, that is. For books that leave out the first two moves, and an engine that considers a2-a4 and equally good move as e2-e4, you would have a similar problem.)

[notnale]

I've always wondered how opening books are actually implemented in typical chess engines

[h.g.muller]

Well, my engines have no opening book. It usually depends on the engine, each engine has its own format. But I recently added probing code for a GUI book to WinBoard, using the Polyglot book format, so I know now how that works.

It seems to be quite a sensible format: it stores (position, move, weight) triples, rather than lines of play. So when you probe the book you retreive all triples for the current position, and pick one of the moves based on the weights. The positions are ordered and recognized by a 64-bit hash key, so that a binary search in the book file can be used to find them (or establish they are not there).

By storing positions you automatically capture transpositions, and can get back in book once you are out. And you don't need to put moves you don't want the engine to play in the book, but still can include the refutations of such moves.

[Codeman]

A little improvement to this would be to, instead of using one 64 bit key for the position + some bytes for the move
one key which contains 32 bit of the old position and 32 bit of the new position.

Thus you save some space, which might be relevant for aligning purposes, without increasing the risk of collisions.