Porting syzgy/tb to an old version chess (shatranj)

[syzygy]

• al-Suli's Diamond

[d]8/8/8/3k4/8/1KF5/8/f7 w - - 0 1
Indeed 39 ply:
1. Kb4 Kd6 2. Kc4 Ke6 3. Kd4 Kf6 4. Ke4 Kg6 5. Qb4 Kf7 6. Ke5 Kf8 7. Ke6 Ke8 8. Kd5 Kd8 9. Qc3 Ke7 10. Qd2 Kf6 11. Kc5 Kf5 12. Kc4 Kf4 13. Kc3 Kf3 14. Kc2 Ke2 15. Qc3 Ke3 16. Qb4 Kd4 17. Kb3+ Kd3 18. Qa3 Kd2 19. Ka2 Qb2 20. Kxb2

[hgm]

I replaced the Q and B symbols in the diagrams by their Shatranj equivalents (F/E).

I put baring code in FairyGen again, and for the position

[d]1e6/8/8/8/5E2/8/8/k1K5 w

it recommends 1.Kc2 with the message "mate in 10". But when I let it play, it forces the position

[d]ke6/8/1K6/8/5E2/8/8/8 b

announcing "mate in 0". This was not quite what I intended, as I had wanted to equate bareness to being in check, and the inability to evade to double bare as checkmate. But apparently I assigned too low a DTM for the "irrecoverably bare" positions. The effect is that it considers the last non-King piece as royal as well, so that the final position is really a stalemate (also losing), rather than a forced Elephant sacrifice.

Of course it is basically a matter of taste how you count the winning distance, and how you compare wins through different methods of winning. From the first to the second Diagram took 21 ply (11 white moves, 10 black), after 11... Ed5 12. Exd5# (23 ply) black is irrecovarably bare. So it is plausible that this is what the syzygy generator meant, and then FairyGen confirms it.

BTW, note that this position could never occur in a Shatranj game. Elephants are severely area bound, and start such that they can never attack or protect each other.

[hgm]

[d]8/8/3F4/8/8/k6f/8/1K6 w
White wins in 63 ply?

FairyGen says "mate in 30", and if we double that and add 3 ply, like in the previous case, that is indeed 63.

[d]8/8/8/8/5F2/7k/2K5/n7 w
White wins in 15 ply?

"Mate in 6" through 1. Kc3 (and then pick off the trapped Knight with the Ferz). 2*6+3 = 15.

[d]2k2F2/8/8/8/8/8/4n3/2K5 w[d]
Black wins in 40 ply?

After 1.Kd2 the black move (1... Ng1) says "mate in 18", and 2*18+3 = 39. So 40 ply in total. (FairyGen in console mode can only play and report DTx for the winning player.)

[d]6Fk/8/7f/8/7F/8/3K4/8 w
White wins in 129 ply (cursed win)

"Mate in 63" (after 1.Qf7). 2x63+3 = 129.

These seem all OK. For the 'Diamond' is says "mate in 18", and 2*18+3 = 39. It also plays the given line, except 19.Qa5 instead of Qa3, but these are equivalent.

The earlier mate in 3 seems due to not recognizing the counter-baring.

White wins in 43 ply:
[d]F7/7k/8/8/f7/8/8/K7 w
This seems suspect. Do you have a way to verify whether this is a win for white?

FairyGen does not see a win here.

[syzygy]

[d]8/8/3F4/8/8/k6f/8/1K6 w
White wins in 63 ply?

FairyGen says "mate in 30", and if we double that and add 3 ply, like in the previous case, that is indeed 63.

Thanks. I have now adapted my engine to play shatranj (or at least let it know the rules), so I can generate the full lines. I think I have now fixed all the bugs (and hopefully did not introduce any in the pawn generation code). The full "mate" (with Q instead of F) here is:
1.Kc2 Ka4 2.Kd3 Kb5 3.Ke4 Kc6 4.Qe5 Kd7 5.Kf5 Kc6 6.Qf4 Kd5 7.Qg5 Qg2 8.Kf4 Qf1 9.Ke3 Ke5 10.Qh4 Kf5 11.Kf3 Kg6 12.Kg4 Qe2 13.Qg3 Qd3 14.Kf4 Qc4 15.Ke5 Kg5 16.Ke4 Qb5 17.Qf4+ Kf6 18.Kd5 Kf5 19.Qe3 Kg4 20.Ke4 Kg3 21.Qd4 Kf2 22.Qe5 Qa4 23.Kd4 Kf3 24.Qd6 Kf4 25.Qc5 Kf5 26.Qb4 Ke6 27.Kc5 Qb3 28.Qa3 Qa2 29.Kb4 Qb1 30.Kb3 Kd5 31.Kb2 Qa2 32.Kxa2

With DTZ I don't have to decide how to "count" a bare king position: the conversion of the position into the bare king position is a zeroing move. And stalemate is simply treated as a mate.

[d]8/8/8/8/5F2/7k/2K5/n7 w
White wins in 15 ply?

"Mate in 6" through 1. Kc3 (and then pick off the trapped Knight with the Ferz). 2*6+3 = 15.

1.Kc3 Kg2 2.Qe5 Kf3 3.Qd6 Ke4 4.Qc5 Kd5 5.Qb4 Kc6 6.Qa3 Kb5 7.Qb2 Nc2 8.Kxc2

[d]2k2F2/8/8/8/8/8/4n3/2K5 w[d]
Black wins in 40 ply?

After 1.Kd2 the black move (1... Ng1) says "mate in 18", and 2*18+3 = 39. So 40 ply in total. (FairyGen in console mode can only play and report DTx for the winning player.)

1.Kd2 Ng1 2.Qg7 Kd7 3.Ke3 Ke6 4.Kf2 Nh3+ 5.Kg3 Ng5 6.Kg4 Nh7 7.Kh5 Kf5 8.Kh6 Ng5 9.Qf8 Ne6 10.Qe7 Nc5 11.Kg7 Ke6 12.Qf8 Nd7 13.Kg8 Kf6 14.Qg7+ Kg6 15.Kh8 Nc5 16.Kg8 Ne6 17.Qh8 Kf6 18.Kh7 Kf7 19.Kh6 Kg8 20.Qg7 Nxg7

[d]6Fk/8/7f/8/7F/8/3K4/8 w
White wins in 129 ply (cursed win)

"Mate in 63" (after 1.Qf7). 2x63+3 = 129.

1.Qf7 Kg7 2.Qe6 Kf6 3.Qd7 Kf5 4.Qg3 Ke4 5.Ke2 Kd5 6.Qc8 Qg5 7.Qb7 Qf6 8.Kf3 Qe7 9.Kf4 Qd8 10.Kf5 Kd6 11.Qf4 Kc7 12.Qa8 Kd6 13.Qe5+ Kd7 14.Qb7 Kc7 15.Qa6 Kc6 16.Ke6 Qc7 17.Ke7 Qb6 18.Kd8 Qa5 19.Kc8 Qb4 20.Qf6 Kd6 21.Qb7 Qc3 22.Kd8 Qd4 23.Qe7+ Ke6 24.Qc6 Qc5 25.Ke8 Qb4 26.Qd7+ Kd5 27.Kf7 Ke5 28.Qe6 Qa3 29.Qf6+ Kd6 30.Qf5 Kd5 31.Kg6 Kd4 32.Kg5 Ke3 33.Qe5 Qb4 34.Qg4 Ke4 35.Kf6 Kd3 36.Kf5 Qa3 37.Qh3 Qb2 38.Kf4 Qa1 39.Qg2 Qb2 40.Qf1 Qa3 41.Kf3 Qb4 42.Qe2+ Kc4 43.Ke4 Kc5 44.Qf3 Qa5 45.Qf4 Qb4 46.Ke5 Qa3 47.Qe2 Qb2 48.Qe3 Kc4 49.Qd4 Qa3 50.Ke4 Qb4 51.Qd3+ Kb3 52.Kf3 Kb2 53.Ke3 Kc1 54.Ke4 Kb2 55.Qc4 Kc2 56.Kd5 Qa3 57.Kc5 Kb2 58.Kb5 Kc2 59.Ka4 Qb2 60.Kb4 Qan1 61.Qc3 Kc1 62.Qb3 Kb1 63.Ka3 Kc1 64.Ka2 Qb2 65.Qxb2+

White wins in 43 ply:
[d]F7/7k/8/8/f7/8/8/K7 w
This seems suspect. Do you have a way to verify whether this is a win for white?

FairyGen does not see a win here.

Indeed this position is a draw. I still had some bugs relating to detecting and evaluating bare king positions, which probably caused this error.

The "hardest" KPPvKP position (not actually hard since my engine finds it immediately even without TBs):
[d]7k/2p5/2P5/8/2P4K/8/8/8 b - -
1...Kg8 2.Kg4 Kf7 3.Kf5 Ke7 4.Ke5 Kf7 5.Kd4 Ke6 6.Kc5 Ke7 7.Kb4 Kd8 8.Ka4 Kc8 9.Kb5 Kb8 10.Kc5 Ka7 11.Kd4 Ka6 12.Ke5 Kb6 13.Kd5 Ka5 14.Ke6 Kb4 15.Kd7 Ka3 16.Kxc7

A "cursed" position (cursed win for white, i.e. black can draw by the 50-move rule):
[d]7K/k6P/8/2p5/8/8/P7/8 b - -
1...Kb6 2.Kg7 Kc6 3.Kf6 Kd6 4.Kf5 Kd5 5.Kf4 Kd4 6.Kf3 Kd3 7.Kf2 Kd2 8.h8=Q
resulting in:
[d]7Q/8/8/2p5/8/8/P2k1K2/8 b - - 0 8
Now the pawns can walk and promote and it ends up in a position that needs more than 50 moves.

Highest DTZ for 5-piece tables (DTZ = 179):
[d]1Q3b2/8/8/8/8/8/8/K2k2B1 w - -
1.Be3 Ke2 2.Bc1 Kd3 3.Qc7 Kc2 4.Be3 Kd3 5.Bg5 Ke4 6.Qb6 Kd5 7.Be3 Kd4 8.Bc5 Kc4 9.Be7 Kd5 10.Qc5 Ke6 11.Bg5 Kd5 12.Be3 Ke4 13.Bc1 Kd5 14.Ba3 Kc4 15.Kb2 Bh6 16.Kc2 Bf4 17.Kd1 Kb3 18.Bc1 Kc4 19.Be3 Kd3 20.Bg5 Kc4 21.Qb6 Kb5 22.Qc7 Kc6 23.Qd8 Kd5 24.Qe7 Bh6 25.Ke2 Ke4 26.Be3 Bf4 27.Bc1 Bh6 28.Ba3 Bf4 29.Kf2 Bd2 30.Qf8 Bf4 31.Kg3 Kf5 32.Bc5 Bh6 33.Qe7 Kg5 34.Ba3 Bf4 35.Kf2 Kf5 36.Kf3 Bh6 37.Bc5 Bf4 38.Kg3 Kg5 39.Be3+ Kf5 40.Kh4 Bd2 41.Bc5 Bb4 42.Kh5 Bd2 43.Kh6 Bb4 44.Kg7 Ke6 45.Qf6 Bd2 46.Ba3 Bb4 47.Bc1 Bd2 48.Kg6 Bb4 49.Qg5 Bd2 50.Qh4 Bb4 51.Qg3 Bd2 52.Ba3 Bb4 53.Qf2 Bd6 54.Qe3 Ke5 55.Kg7 Bb4 56.Bc1 Bd6 57.Kf7 Bb4 58.Ke7 Bd6 59.Qd4+ Kd5 60.Ba3 Bb4 61.Qc3 Bd6 62.Kf6 Bf4 63.Bc1 Bd6 64.Be3 Bf4 65.Bg5 Bd6 66.Qd2 Bb4 67.Qe3 Bd6 68.Kf5 Bb4 69.Qf4 Bd2 70.Qe5

Hmmm, why does this end too soon... maybe still a bug (either in the generator or in my engine).

[syzygy]

Highest DTZ for 5-piece tables (DTZ = 179):
[d]1Q3b2/8/8/8/8/8/8/K2k2B1 w - -
1.Be3 Ke2 2.Bc1 Kd3 3.Qc7 Kc2 4.Be3 Kd3 5.Bg5 Ke4 6.Qb6 Kd5 7.Be3 Kd4 8.Bc5 Kc4 9.Be7 Kd5 10.Qc5 Ke6 11.Bg5 Kd5 12.Be3 Ke4 13.Bc1 Kd5 14.Ba3 Kc4 15.Kb2 Bh6 16.Kc2 Bf4 17.Kd1 Kb3 18.Bc1 Kc4 19.Be3 Kd3 20.Bg5 Kc4 21.Qb6 Kb5 22.Qc7 Kc6 23.Qd8 Kd5 24.Qe7 Bh6 25.Ke2 Ke4 26.Be3 Bf4 27.Bc1 Bh6 28.Ba3 Bf4 29.Kf2 Bd2 30.Qf8 Bf4 31.Kg3 Kf5 32.Bc5 Bh6 33.Qe7 Kg5 34.Ba3 Bf4 35.Kf2 Kf5 36.Kf3 Bh6 37.Bc5 Bf4 38.Kg3 Kg5 39.Be3+ Kf5 40.Kh4 Bd2 41.Bc5 Bb4 42.Kh5 Bd2 43.Kh6 Bb4 44.Kg7 Ke6 45.Qf6 Bd2 46.Ba3 Bb4 47.Bc1 Bd2 48.Kg6 Bb4 49.Qg5 Bd2 50.Qh4 Bb4 51.Qg3 Bd2 52.Ba3 Bb4 53.Qf2 Bd6 54.Qe3 Ke5 55.Kg7 Bb4 56.Bc1 Bd6 57.Kf7 Bb4 58.Ke7 Bd6 59.Qd4+ Kd5 60.Ba3 Bb4 61.Qc3 Bd6 62.Kf6 Bf4 63.Bc1 Bd6 64.Be3 Bf4 65.Bg5 Bd6 66.Qd2 Bb4 67.Qe3 Bd6 68.Kf5 Bb4 69.Qf4 Bd2 70.Qe5

Hmmm, why does this end too soon... maybe still a bug (either in the generator or in my engine).

After 50 moves the following position is reached:
[d]8/8/4k1K1/8/1b5Q/8/8/2B5 w - - 0 1
From here (counting from 1 instead of 51):
1.Qg3 Bd2 2.Ba3 Bb4 3.Qf2 Bd6 4.Qe3 Ke5 5.Kg7 Bb4 6.Bc1 Bd6 7.Kf7 Bb4 8.Ke7 Bd6 9.Qd4+ Kd5 10.Ba3 Bb4 11.Qc3 Bd6 12.Kf6 Bf4 13.Bc1 Bd6 14.Be3 Bf4 15.Bg5 Bd6 16.Qd2 Bb4 17.Qe3 Bd6 18.Kf5 Bb4 19.Qf4 Bd2 20.Qe5 Bb4 21.Kf4 Bd2+ 22.Ke3 Bb4 23.Qf6 Bd6 24.Qe7 Bb4 25.Kd3 Kc5 26.Be3+ Kb5 27.Qf6 Bd6 28.Qe5 Bb4 29.Kc3 Ka5 30.Qd4 Bd6 31.Kc4 Bf4 32.Kd5 Bd2 33.Ke4 Kb4 34.Kd3 Bf4 35.Qe5 Bh6 36.Ke4 Bf8 37.Kf5 Bh6 38.Kf6 Bf8 39.Kg7 Bd6 40.Qxd6

So in total indeed 179 ply. And the two lines are identical, except that my engine for some reason cut the first one at move 70 (even though I had just increased the limit to 250 ply).

[syzygy]

Six years ago I generated 4- and 5-men EGT for Shatranj. See https://kirill-kryukov.com/chess/discus ... 15a517963c . This describes what I had to change in the generator to implement that bare-king rule.

I'm afraid it was more than six years ago... time flies

[syzygy]

I will probably give it a try myself.

So that would be awesome, because even understanding your suggestions would take a while for me , having another option inside tb repo for shatranj would be really usefull (jtbgen.c).

I have pushed my modifications to github, so now you should be able to compile jtbgen and jtbgenp.

If you have a shatranj version of Stockfish, then you will have to adapt the probing code to:
- look for .jtbw and .jtbz files instead of .rtbw and .rtbz
- use the WDL_MAGIC and DTZ_MAGIC values for SHATRANJ defined in probe.h
- at the beginning of the search() function in tbprobe.cpp, test whether the side-to-move has a bare king (pos.count(Us) == 1) and return the correct value (so loss unless there are 3 pieces in total, i.e. pos.count(Them) == 2, and something like (attacks_bb<KING>(pos.square<KING>(Us), Us) & ~attacks_bb<KING>(pos.square<KING>(Them), Them) & pieces()) != 0).

There should be no need to test for stalemate in the probing code, at least not for WDL probes, since stalemates are stored. (It might be necessary to test for stalemate for DTZ probes to get the returned value correct.)

[noobpwnftw]

I'll do the full 6 men tables with your generator.

https://www.chessdb.cn/egtb_infoj.html

Files will be shared after they are built.

[hgm]

With DTZ I don't have to decide how to "count" a bare king position: the conversion of the position into the bare king position is a zeroing move. And stalemate is simply treated as a mate.

Indeed. I was puzzled by the winning distance reported by FairyGen for the baring, but I had not realized FairyGen was also running in DTC mode. And like you say, the baring must be a conversion. That I count the position before black has to expose its last piece with the same DTC as checkmate is because the 50-move rule not applying in positions that are checkmates.

BTW, did Shatranj have a 50-move rule? It would make no sense there, as this rule is based on the length of KBNK in FIDE (+50%), which does not exist in Shatranj. End-games there typically last much longer. Makruk, which is more Shatranj-like then FIDE has a 64-move rule.

[syzygy]

I'll do the full 6 men tables with your generator.

https://www.chessdb.cn/egtb_infoj.html

Files will be shared after they are built.

Nice. I hope the generator is now fully correct. I have not extensively tested stalemate, etc.

There should be 360 tables with 4/5/6 pioeces (15/75/270).