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).