Syzygy question

[hgm]

How much are syzygy EGT and their probing code aware of the identity of the pieces? Is this just in the filenames? In other words, would the probing code need any changes if it were to be used for a chess variant with pieces that are identified by different letters, other than that the corresponding tables would need names that use these different piece IDs tfor indicating the piece composition of the end-game they are for?

[gflohr]

I have recently, about a month or two ago, ported the Syzygy probing code from python-chess to Perl without understanding it in all details.

Yes, the piece letters are in the filenames, but that should be trivial to change.

In the (Python!) probing code, the pieces seem to be hardcoded as integers 1 (pawn) to 6 (king). At least, these are the numerical constants I am using, and the code worked without changes. I'm not 100 % sure about the original C version.

The colours in the C code are probably 0 for white and 1 for black. In python-chess it is the opposite. White is True (1) and black is False (0), and I had to modify the logic to reflect this difference because my library uses 0 for white and 1 for black.

I do remember that the code very often distinguishes between pawns and other pieces because pawn pushes reset the halfmove counter for the 50-move rule. But maybe this is also because of the somewhat odd movement and capturings of pawns in classical chess.

The tables ignore the possibility of en-passant captures (and castling if that matters). En-passant is handled by a wrapper around the actual lookup code. In a nutshell, if en-passant is possible, the one or two en-passant captures are also tried out, and if one of them yields a better result, that result is returned. If your variant doesn't have en-passant, you can bypass that.

[syzygy]

How much are syzygy EGT and their probing code aware of the identity of the pieces? Is this just in the filenames? In other words, would the probing code need any changes if it were to be used for a chess variant with pieces that are identified by different letters, other than that the corresponding tables would need names that use these different piece IDs tfor indicating the piece composition of the end-game they are for?

The identity of the pieces is stored in the tablebase file but only to know the order in which they have been indexed. The indexing code basically only distinguishes between pawns and non-pawns. It mostly does not even rely on there being two kings which cannot be on neighbouring squares (because I found not treating the Ks differently leads to smaller compressed files even though the indexing space increases a bit, the reasoning being it gives more possibilities for changing the order of pieces). Only for tables such as KQQvK which do not have 3 "non-like" pieces does the code use KK-based indexing (for the compressed file).

For generating the files the code uses KK-based indexing for regular chess but a 10x64^(n-1) scheme for variants such as atomic and suicide/giveaway where the KKs can be on neighbouring squares (or be entirely absent).

[syzygy]

How much are syzygy EGT and their probing code aware of the identity of the pieces? Is this just in the filenames? In other words, would the probing code need any changes if it were to be used for a chess variant with pieces that are identified by different letters, other than that the corresponding tables would need names that use these different piece IDs tfor indicating the piece composition of the end-game they are for?

Is there are a list of fairy piece types that respect the 8 board symmetries and capture like regular pieces?

I am thinking of a new or extended TB format to allow for some new indexing and compression methods.
Instead of pieces types 1-6 and 9-14, I could easily encode the color in the msb, so there would be piece types 1-127 for white and 129-255 for black. I think that should leave enough space?

[hgm]

In principle there is an infinite number of such pieces, but a board size of 8x8 would limit that. Each 8-fold-symmetric move set can be represented by the square in the triangular sector a1-a8-h8 it could reach from a1 (even a1 itself, which would represent a null move). And each such set could be present in the move set of a piece or not. Short-range leaps (up to 2 King steps) are quite common, and occur in any combination, and without the rather uncommon null move (and excluding pieces without any moves) that already makes 31 piece types. Leaps to the 3rd ring are less common, but they do still occur frequently, often in combination with moves of a single King steps. And then I am still ignoring compounds that combine slides with leaps, such as the Archbisjop = B+N.

To cover all that would probably lead to more than 128 types.

But I wonder if that is important. The indexing of an EGT can simply number pieces from 0 to N, and the probing code has to map an engine's internal coding of the piece types to these numbers based on which EGT it is probing. This mapping could be encoded in the filename, e.g. egt-K.B.N-K.bin could be used for the KBNK end-game, and an engine using royals with a King move, Bishops and Knights would know when it should try to load and probe this EGT. The piece types could be encoded by the Betza notation of their move.

Fairy-Stockfish would already know the Betza notation for each piece that occurs in any of its variants, (e.g. BN for the Archbishop) for sending those to the GUI. It could also use these for finding the EGT file to probe.