Seirawan chess

[ianfab]

If anyone is interested, I have uploaded a first version for an implemenation of Seirawan chess in Stockfish: https://github.com/ianfab/Seirawan-Stockfish. Only the rules are implemented without any evaluation or search changes compared to standard chess (apart from introducing piece values for hawk and elephant), so it might not be that strong, and there might still be bugs. Nevertheless, in a first test with XBoard/Winboard it seemed to work fine (and of course it defeated me :-D ).

I have not implemented it in multi-variant Stockfish for a couple of reasons:

• move encoding would perhaps have to be even uglier as it is in my implementation if you also want to make it fit into 16 bits while preserving crazyhouse and antichess functionality
• code might become more fragile when tinkering with additional piece types while preserving functionality for other variants and standard chess
• maintenance would become more difficult
• adding new piece types blows up array sizes
• it is very likely that it would cause a slowdown for standard chess (although that is a minor issue since it could simply be disabled via the makefile if not needed)

I still think it should be possible to somehow make it work in multi-variant Stockfish, but for the reasons mentioned above I think it is better to keep it separate from the variants without fairy pieces.

[ddugovic]

Very nice!

I'll continue trying to port Stockfish to Rust (or D, or other high-level abstract language) to help with scalability of new variants.

[alwey]

FYI: In June I tried to implement seirawan (Seirawan Chess, SHarper Chess, S-Chess) for cutechess. Sadly, this variant made more difficulties than anticipated, and more than any other variant. So it is not ready yet.

[ianfab]

@alwey Thanks for the info. Cutechess for Seirawan chess would be great as it would then be possible to run tests for Seirawan-Stockfish on fishtest. Since cutechess already supports capablanca chess, I guess the difficulties had to do with gating moves. In Stockfish, implementing castling with gating on the rook square was a bit tricky.

[ianfab]

By the way, does anyone have a list of engines supporting Seirawan chess or maybe even a rating list? The only engine of which I know it supports S-chess is Sjaak.

A first match against Sjaak II 1.4.1 revealed two bugs in Stockfish, and after fixing them in a second match Stockfish won 97.5 - 2.5 at very short time control (10''+0'') with no time losses or crashes on either side. I think this is not really surprising since S-chess is a superset of standard chess with not that many additions, so Seirawan-Stockfish can inherit large parts of the playing strength of standard Stockfish.

[alwey]

@ianfab : You are right, the gating moves made problems, and FEN notation needed some effort. My seirawan branch of cutechess implements a FEN-notation defined by @HGMuller. Internally the gating moves are coded as optional promotions, not as drops. Castling in combination with gating is left out yet, so this software is not usable. It is not even stable.

Being unsure whether there is demand for the variant I gave the seirawan branch a rest.

---

Playing two instances of Fairy-Max 5.0b Xboard's PGN notation looks like: `1. Nc3/E {+0,14/6} Nc6/E {+0,17/6 0,5} 2. d4 {+0,07/6 0,5} f6 {+0,04/6 0,7}

3. Be3/H {+0,11/6 1,0} Nh6/H {+0,24/6 0,7}`.

Now a new game with cutechess GUI, of course it did not go through:

[Event "?"]
[Site "?"]
[Date "2017.10.23"]
[Round "?"]
[White "fairymax"]
[Black "sjaakii-1.4.1"]
[Result "0-1"]
[PlyCount "26"]
[Termination "stalled connection"]
[TimeControl "30+0.3"]
[Variant "seirawan"]

1. Nc3 {+0.26/7 1.4s} d5 {-0.06/12 1.1s} 2. d3 {+0.16/7 1.3s}
Nf6 {+0.05/10 1.1s} 3. a3 {+0.02/6 0.46s} d4 {+0.12/11 1.2s}
4. Ne4 {-0.08/7 0.41s} Nc6 {+0.15/10 1.1s} 5. Nf3 {+0.04/7 0.56s}
Qd5/E {+0.10/9 0.89s} 6. c4 {+0.03/7 0.67s} Qf5 {-0.23/10 1.2s}
7. Ng3 {-0.02/7 0.69s} Qc5 {-0.35/11 1.1s} 8. Qc2 {+0.03/6 0.47s}
a5 {+0.41/8 0.57s} 9. Bd2 {+0.11/6 0.43s} h5 {+1.45/8 0.59s}
10. O-O-O {+0.17/6 0.40s} h4 {+6.19/10 0.57s} 11. Ne4 {-0.14/8 0.57s}
Nxe4 {+6.52/11 0.80s} 12. dxe4 {-0.12/7 0.49s} h3 {+6.49/10 1.3s}
13. gxh3 {-0.03/8 0.93s} Ed6 {+5.77/9 1.3s, White's connection stalls} 0-1

White did not like d8d6, it reported an illegal move.

[alwey]

Stockfish played its first Seirawan game on cutechess - and won with Black:

[Event "?"]
[Site "?"]
[Date "2017.10.23"]
[Round "?"]
[White "sjaakii-1.4.1"]
[Black "stockfish-s-47ed2a7"]
[Result "0-1"]
[PlyCount "88"]
[TimeControl "30+0.3"]
[Variant "seirawan"]

1. d3 {+0.05/10 1.9s} Nc6/H {+0.50/14 2.9s} 2. Nf3 {+0.37/9 0.92s}
d5 {+0.07/14 1.3s} 3. c3 {+0.28/9 1.4s} e5 {+0.79/14 2.1s} 4. h3 {+0.18/8 1.0s}
Nf6/E {+1.17/13 1.6s} 5. g4 {+0.27/8 1.2s} Qe7 {+0.92/12 1.9s}
6. g5 {+0.59/8 1.2s} Nh5 {+0.50/17 2.2s} 7. a4 {+0.56/8 0.54s}
e4 {+1.17/14 3.5s} 8. dxe4 {+0.66/8 0.63s} dxe4 {+1.26/15 0s}
9. Nd4 {+0.59/8 0.84s} Ne5 {+1.21/15 1.4s} 10. b3 {+0.71/6 0.76s}
c5 {+1.70/13 1.1s} 11. Nb5 {+0.34/9 1.3s} a6 {+2.25/12 0.61s}
12. N5a3 {+0.19/9 1.5s} Hc6 {+2.27/16 2.1s} 13. Nc4 {-0.08/8 1.1s}
Nxc4 {+1.91/13 0.98s} 14. bxc4 {-0.53/10 1.2s} e3 {+2.29/15 1.2s}
15. Bg2/H {+0.23/9 1.2s} exf2+ {+0.94/16 1.6s} 16. Kxf2 {+0.37/8 1.1s}
Ha5 {+1.04/17 0.001s} 17. Bd5 {+0.60/7 0.53s} h6 {+1.82/14 1.4s}
18. Hd2 {+0.47/6 0.68s} hxg5 {+2.45/15 0.61s} 19. Hxg5 {+0.18/8 0.77s}
Nf6 {+2.77/16 0.22s} 20. Qd3 {+0.72/5 0.51s} Rh5 {+4.02/15 0.40s}
21. Hd2 {-1.23/7 0.78s} Nxd5 {+7.54/14 0.47s} 22. cxd5 {-3.56/7 0.51s}
Ef6+ {+7.24/15 0.82s} 23. Hf3 {-3.84/8 0.70s} Rf5 {+7.18/17 0.61s}
24. Re1/E {-3.24/8 0.92s} Hc7 {+7.27/17 1.5s} 25. c4 {-4.16/7 0.94s}
Eg6 {+7.31/18 0.092s} 26. Qe3 {-2.91/7 0.51s} He5 {+8.24/15 0.69s}
27. Rg1 {-5.05/7 0.49s} Qh4+ {+10.38/17 0s} 28. Eg3 {-7.27/7 0.89s}
Be7 {+13.38/19 0.56s} 29. Qxe5 {-8.34/8 0.66s} Exe5 {+13.64/21 0.001s}
30. Nd2 {-8.97/8 0.54s} Rxf3+ {+14.57/19 0.52s} 31. exf3 {-10.03/9 0.77s}
Ed3+ {+18.41/18 0.50s} 32. Ke2 {-9.91/8 0.43s} Ec3+ {+20.04/18 0s}
33. Kf2 {-13.90/8 0.71s} Bd6 {+21.79/19 0s} 34. Ne4 {-14.90/8 0.50s}
Bxg3+ {+22.92/16 0.26s} 35. Rxg3 {-14.94/9 0.40s} Ec2+ {+25.45/15 0.18s}
36. Bd2 {-15.26/9 0.34s} Exa1 {+26.48/16 0.17s} 37. a5 {-15.89/9 0.75s}
Bxh3 {+64.24/17 0.40s} 38. Ke3 {-17.25/7 0.49s} Bf1 {+M13/24 0.53s}
39. Nd6+ {-M14/6 0.33s} Kf8 {+M11/26 0.001s} 40. Rg4 {-M10/7 0.50s}
Ec2+ {+M9/30 0.11s} 41. Kf4 {-M8/4 0.027s} Ed4+ {+M7/31 0.089s}
42. Ke3 {-M6/3 0.004s} Ed3+ {+M5/67 0.57s} 43. Ke4 {-M4/2 0s}
Qe7+ {+M3/73 0.18s} 44. Kf5 {-M4/2 0.023s} Qe5# {Black mates} 0-1

[ianfab]

@alwey If you would like to have an engine that does not take into account gating by castling in order to be able to test an incomplete implementation, then I could easily create a branch of Seirawan-Stockfish for this purpose. Let me know if this would be helpful.

My implementation should be relatively stable now as it shows the same perft results as Sjaak up to depth 6 (did not test more as perft is slow in Sjaak), and I did not get any more illegal moves in the last 100 test games against Sjaak.

[alwey]

@ianfab : Thank you, but Stockfish is really fine as is. I am just testing with the CLI against Sjaak II 1.4.1. Sadly, my software currently is instable and crashes now and then. Normally, I do not have any crashes while developing other variants.

[alwey]

@ianfab : I guess Stockfish exceeds Sjaak II 1.4.1 by about 600 Elo at 30s+.3s (result 135:3) When Stockfish played with 10s+.1s against Sjaak II 1.4.1 at 60s+.6s the result was 89.5:10.5.

[ianfab]

@alwey Thanks for testing. I guess that longer TC helps Stockfish to avoid blunders (possibly due to things still on my todo list, such as that hash does not depend on the possible gating squares).

Edit: I overlooked that the second test included a time handicap. Interesting result.

[alwey]

@ianfab: I think the result at 10s+0.1 is also consistent with 600 Elo difference in playing strength, because Sjaak II was given a time handicap of about 2.5 doublings. In standard chess and for Stockfish-7, one doubling is worth about 100 Elo in the 10s range, but more for shorter time controls and less for longer time controls.

[alwey]

Seirawan engines:

Sjaak II (E. Glebbeek), Fairy-Max (H. G. Muller), Sigla (F. Mosca, only Windows binary), Leonidas (also E. Glebbeek).

http://computer-chess.org/doku.php?id=computer_chess:wiki:lists:variants_engine_list

[HGMuller]

I have made a version of Fruit 1.2 that can play S-Chess. But it became unstable when I added the possibility to gate at the Rook square on castling, and I never got to resolving that.

I am also in possession of a S-Chess version of Komodo. But it was given to me in confidence as a private engine. The owner is Frank Camaratti  of House of Staunton, who ordered it from Don Daily. He never did anything to market it, which I think was a mistake, as Stockfish now probably will be stronger.

[ianfab]

@HGMuller Thanks a lot for the info, that's very interesting. Since you can not share the Komodo version, could you maybe run a short S-Chess match of Stockfish vs. Komodo offline and post the results? Something like 50-100 games at a time control comparable to fishtest STC would be totally sufficient, I would just like to get a rough idea of the sign and order of magnitude of the Elo difference.

[Just in case you missed it, there is another thread where your feedback would be very much appreciated.]

[HGMuller]

Yes, I should be able to do that, in principle. I never succeeded in compiling Stockfish, however, and I don't have a 64-bit compiler anyway. So it would be helpful if you could give me a link to a Windows executable. (I have an i7-2600 (Sandy Bridge).) I also hope there are no incompatibilities between the way Komodo handled FENs and moves, and Stockfish does; the current version of UCI2WB should work with Komodo; the reason I have this Komodo was actually to make that happen.

[ianfab]

I also have never compiled Stockfish under Windows. Maybe someone else could help out with that?

I followed your FEN format definition when developing Seirawan-Stockfish, and I tried it with UCI2WB in Xboard (although not up to date), so I hope it should in principle work fine.

[ddugovic]

So far I've registered with Appveyor #351 but have not figured out how to configure those Windows builds to enable variants.

[Vinvin20]

Dann Corbit : http://www.talkchess.com/forum/profile.php?mode=viewprofile&u=58 could probably do that.

[MichaelB7]

@hgmuller - his name is Frank Cammarata, a very nice man and a smart businessman.

[HGMuller]

Martin Sedlak made a Windows compile for me, and I was able to play it against Seirawan-Komodo (game below). After a somewhat embarrassing end-game, Komodo won that one. Apparently due to an advantage acquired very early in the opening.

About the test match: does Seirawan-Stockfish randomize in any way, or is it practically deterministic? In other words, does it make sense to play a match without opening book? If not, do you have a book?

[Event "Computer Chess Game"] [Site "MAKRO-PC"] [Date "2017.11.02"] [Round "-"] [White "Schess64 12.0002 (UCI2WB)"] [Black "Stockfish 011117 64 (UCI2WB)"] [Result "1-0"] [TimeControl "40/300"] [Variant "seirawan"] [Annotator "1. +0.27 1... -0.43"]

1. e4 {+0.27/14} e5 {-0.43/18 16} 2. Nf3 {+0.20/12 7} f5 {-0.03/17 17} 3. exf5 {+0.85/11 9} Nc6/H {-0.05/18 11} 4. d4 {+1.09/11 6} Bb4/E+ {-0.67/20 25} 5. c3 {+2.65/13 4} Be7 {-2.30/20 10} 6. Bd3 {+2.23/13 8} e4 {-2.47/23 17} 7. Bxe4 {+2.33/12 0.9} d5 {-2.75/23 9} 8. Bd3 {+2.40/14 8} Bxf5 {-2.56/18 2.1} 9. O-O/H {+2.04/14 21} Hd7 {-2.25/19 5} 10. Hc2 {+2.15/13 4} Bd6 {-1.64/22 10} 11. Re1+ {+2.16/11 4} Nge7 {-1.69/22 5} 12. b4 {+2.14/12 6} a6 {-1.86/21 9} 13. a4 {+2.34/13 5} Hc8 {-1.67/21 6} 14. b5 {+2.42/12 5} axb5 {-1.42/23 27} 15. axb5 {+2.35/15 7} Rxa1 {-1.83/22 7} 16. Hxa1 {+2.43/15 6} Bg4 {-1.81/23 5} 17. bxc6 {+2.93/11 0.4} Bxf3 {-0.11/18 2.4} 18. Qxf3/E {+2.62/16 7} Exf3+ {-0.88/22 7} 19. gxf3 {+2.90/14 0.5} bxc6 {-1.11/19 0.6} 20. Hc2 {+2.70/16 6} Rf8 {-0.86/21 6}
2. Nd2 {+2.90/14 5} Rf6 {-0.71/21 4} 22. Ba3 {+3.45/14 8} Kf7 {-1.00/23 15} 23. Kh1 {+3.04/13 5} Qf8 {-1.13/24 9} 24. Bxd6 {+3.47/14 5} cxd6 {-1.66/24 6} 25. Re3 {+3.13/14 6} Hh3 {-0.88/20 3} 26. Bf1 {+2.74/16 20} Hf4 {-1.54/24 10} 27. Hd3 {+2.81/16 5} Hg5 {-2.01/26 15} 28. Bg2 {+2.61/14 5} Ng6 {-1.17/20 4} 29. Hb4 {+2.26/15 6} Hh4 {+0.00/19 1.6}
3. Hxc6 {+2.37/14 4} Nf4 {+0.00/25 2.0} 31. Bf1 {+2.44/12 0.9} Rg6 {+0.00/27 0.7} 32. Ne4 {+0.40/15 7} dxe4 {+0.30/17 1.2} 33. Hxe4 {+0.59/16 4} d5 {+0.00/23 5} 34. Hg3 {+0.51/18 5} Hg5 {+0.00/25 2.1} 35. c4 {+1.23/16 11} Hh6 {+0.03/21 4} 36. Hh4 {+1.39/14 0.5} Rg5 {+0.00/22 5} 37. Re5 {+1.51/16 5} Rxe5 {-0.68/21 0.5} 38. dxe5 {+1.58/15 1.0} Ng6 {-0.51/22 1.9} 39. Hg2 {+1.80/16 6} Kg8 {-0.58/23 3} 40. cxd5 {+1.39/16 7} Nxe5 {-0.63/23 0.7} 41. Be2 {+1.55/17 6} Hf7 {-0.08/25 5} 42. Hf4 {+1.54/18 9} Ng6 {-0.35/28 14} 43. He6 {+1.19/16 5} Hxe6 {-0.38/32 20} 44. dxe6 {+1.14/15 0.6} h6 {-0.41/29 4} 45. Ee3 {+1.83/17 6} Qf6 {-0.41/31 11}
4. Bc4 {+1.85/18 10} Kh8 {-0.52/33 28} 47. h3 {+1.86/19 6} Ne7 {-0.50/27 6} 48. Kg2 {+1.92/17 5} Ng6 {-0.46/31 10} 49. Ee4 {+1.93/19 11} Qf5 {-0.50/31 7} 50. Kg3 {+1.98/17 6} Ne7 {-1.32/31 18} 51. h4 {+1.99/19 7} g6 {-1.42/33 8} 52. Kg2 {+2.14/19 9} Qf8 {-1.51/36 9} 53. Bd3 {+2.37/19 8} Kg7 {-1.44/37 4} 54. Ed6 {+2.51/19 6} h5 {-1.51/38 1.4} 55. Ed7 {+2.50/23 6} Qf6 {-2.05/38 11} 56. Ed8 {+2.40/21 8} Kh6 {-2.14/36 1.5} 57. Be4 {+2.51/22 6} Kh7 {-3.00/37 13} 58. Bc2 {+2.49/21 10} Qg7 {-1.90/35 4}
5. Ee8 {+2.51/22 6} Nd5 {-2.16/39 14} 60. Ed6 {+2.50/22 9} Ne7 {-2.28/34 1.1} 61. Ed8 {+2.50/21 6} Qg8 {-2.37/39 8} 62. Ed7 {+2.58/23 7} Qg7 {-2.37/40 1.7} 63. Be4 {+2.46/21 7} Kh6 {-2.37/41 5} 64. Kh3 {+2.44/20 6} Qh7 {-2.37/43 7} 65. f4 {+2.47/22 7} Qg7 {-2.37/45 9} 66. Kh2 {+2.48/21 9} Qb2 {-2.37/42 5} 67. Kg2 {+2.46/21 8} Qg7 {-2.90/40 8} 68. Bc2 {+2.50/21 8} Kh7 {-2.65/35 3} 69. Bd3 {+2.51/20 7} Kh6 {-2.45/36 4} 70. Kg3 {+2.45/20 7} Kh7 {-2.45/35 5} 71. Kf3 {+2.43/19 6} Kh6 {-2.98/43 17} 72. Kg2 {+2.48/21 9} Kh7 {-2.96/39 6} 73. Kg3 {+2.44/19 7} Kh6 {-2.96/42 9} 74. Kf3 {+2.45/20 6} Kh7 {-2.85/38 2.2} 75. Be4 {+2.45/21 15} Kh6 {-2.93/37 5}
6. Kg2 {+2.42/19 6} Kh7 {-2.84/42 10} 77. Kh2 {+2.35/20 20} Kg8 {-2.78/34 2.3} 78. Kg1 {+2.36/19 13} Kh8 {-2.77/36 2.4} 79. Kh1 {+2.37/19 5} Kh7 {-3.07/37 4} 80. Bd3 {+2.37/20 14} Kh6 {-1.91/8 0.1} 81. Bc2 {+2.49/19 8} Kh7 {-2.19/38 13} 82. Kg2 {+2.38/19 5} Kh6 {-2.19/36 1.3}
7. Kh2 {+2.41/19 6} Qh7 {-2.13/40 10} 84. Bd3 {+2.39/20 5} Qg7 {-1.96/39 11} 85. Kh3 {+2.37/21 6} Kh7 {-2.38/42 13} 86. Be4 {+2.44/20 5} Kg8 {-2.46/41 11} 87. Ec7 {+2.41/19 5} Kh8 {-2.55/42 15} 88. Kh2 {+2.43/19 7} Kh7 {-2.55/42 6} 89. Ec5 {+2.42/21 7} Kg8 {-2.57/40 9} 90. Ed7 {+2.45/20 7} Kh7 {-2.60/41 7} 91. Kg2 {+2.44/20 6} Kh6 {-2.71/40 9} 92. Bc2 {+2.42/19 6} Qh7 {-2.61/37 4} 93. Bd3 {+2.45/20 7} Qg7 {-2.72/38 1.3} 94. Kg3 {+2.44/20 6} Qh7 {-2.79/39 11} 95. Kf3 {+2.41/19 7} Qg7 {-3.25/45 13}
8. Kg2 {+2.43/20 6} Kh7 {-3.25/41 8} 97. Bb1 {+2.41/19 6} Kg8 {-3.25/38 6}
9. Be4 {+2.43/20 7} Kh8 {-3.25/41 6} 99. Ec7 {+2.44/18 14} Qf8 {-3.17/38 5} 100. Kg3 {+2.40/19 8} Kg7 {-3.17/39 1.8} 101. Bd3 {+2.44/20 5} Kh6 {-2.80/39 9} 102. Ed7 {+2.41/21 7} Qg7 {-2.95/40 2.9} 103. Kf3 {+2.57/21 23} Kh7 {-2.65/38 4} 104. Ke4 {+2.66/20 6} Kh6 {-6.63/36 13} 105. Bc4 {+2.39/21 6} Kh7 {-12.47/43 1:02} 106. Bb5 {+2.34/21 18} Kh6 {-12.47/29 4} 107. Ba6 {+2.35/20 6} Qc3 {-2.14/24 2.2} 108. Ee5 {+2.50/18 5} Qb4+ {-2.36/24 1.1} 109. Kf3 {+3.10/20 6} Qb3+ {-3.89/34 11}
10. Kg2 {+3.35/22 5} Qd5+ {-3.99/41 3} 111. Kg3 {+3.49/26 6} Nf5+ {-3.54/34 1.6} 112. Kh2 {+3.52/22 0.5} Qxe5 {-4.04/35 0.5} 113. fxe5 {+3.92/22 2.1} Kg7 {-5.87/37 8} 114. Bd3 {+4.28/24 8} Ne7 {-6.00/31 0.7}
11. Be4 {+4.82/26 6} Kh6 {-6.55/39 7} 116. Kg3 {+4.87/23 34} Kh7 {-6.62/35 3} 117. Kf4 {+3.65/19 6} Kh6 {-6.55/32 1.2} 118. Ke3 {+5.92/24 4} Kg7 {-6.77/31 0.5} 119. Kd4 {+6.87/25 5} Kf8 {-6.45/28 1.2} 120. Kd3 {+6.05/23 4} Kg7 {-8.06/35 3} 121. Kc4 {+7.02/24 5} Kf8 {-18.86/34 20} 122. Kd4 {+7.14/24 5} Kg8 {-5.95/31 5} 123. Kc5 {+8.67/26 7} Kf8 {-63.34/33 20}
12. Kd6 {+7.52/25 17} Ke8 {-63.21/32 8} 125. Kc7 {+8.84/26 7} Ng8 {-66.70/31 18} 126. Bxg6+ {+8.84/28 5} Ke7 {-67.14/30 1.6} 127. Bf5 {+8.92/27 29} Ke8 {-1000.18/44 14} 128. Bh7 {+16.54/22 27} Ne7 {-1000.19/49 6} 129. Be4 {+1000.15/15 0.2} Ng8 {-1000.18/48 1.2} 130. Kd6 {+1000.14/13 0.2} Ne7 {-1000.19/51 6} 131. f4 {+1000.13/12 0.2} Kd8 {-1000.11/57 8} 132. f5 {+1000.12/13 0.1} Nc8+ {-1000.10/65 6} 133. Kc5 {+1000.12/14 0.2} Ke7 {-1000.09/64 1.3} 134. Bb7 {+1000.10/13 0.1} Na7 {-1000.08/67 6} 135. Kb6 {+1000.08/9 0.2} Kf8 {-1000.07/70 1.3} 136. f6 {+1000.07/8 0.1} Kg8 {-1000.05/93 6} 137. Kxa7 {+1000.06/6 0.1} Kh7 {-1000.05/127 1.9} 138. e7 {+1000.05/6 0.1} Kg6 {-1000.04/127 0.2} 139. Be4+ {+1000.04/3 0.1} Kf7 {-1000.03/127 0.2} 140. Kb6 {+1000.03/2 0.1} Ke8 {-1000.02/127 0.2} 141. Bg6+ {+1000.02/1 0.1} Kd7 {-1000.01/1 0.1} 142. e8=Q# {+1000.01/1 0.1} {Xboard adjudication: Checkmate} 1-0

[ianfab]

@HGMuller Nice. In principle it is deterministic in the same way as standard Stockfish is, so apart from variations due to timing and multi-threading its results will not change. I can try to merge Seirawan-Stockfish with my variant opening book generator to generate an EPD unless someone finds an existing opening book. I hope I can do that tonight, otherwise it will not be possible for me before next week.

[MichaelB7]

I can try to merge Seirawan into the book generator and if successful will post opening book.

[ianfab]

@MichaelB7 That would be nice. Please note that it perhaps requires a series of cherry-picks instead of a simple merge or rebase, since the book generator is based on the multi-variant fork whereas seirawan-stockfish is based on official stockfish.

(I only accidentally closed the issue.)

[HGMuller]

Well, I played 100 games, and on quick inspection they all started the same. So I guess they are not very independent. Stockfish lost 20 games on time. (This was at 40 moves / 1 min.)

[ianfab]

@HGMuller I have uploaded an S-Chess version of the book generator and a generated EPD book. (I have also updated bookgen master with the additions of extinction chess and twokings support.)

I do not know what causes the time losses. Have you observed similar problems for standard Stockfish or multi-variant Stockfish, or is it exclusively for Seirawan-Stockfish?

[MichaelB7]

@HGMuller I can get engine vs engine game going in xboard (macOS) - but what is the trick for a human to play a move like 1. .... Nc6/H. If I play Nc6, white immediately starts thinking? How can I play Nc6 and drop the hawk at the same time and xboard recognize it.? nevermind 😀 , I figured it out ( click gated piece and then simply make move) . See below for 6 ply S-openings.

This is the engine line in xboard.conf:

"/Users/michaelbyrne/cluster.mfb/SF-Seirawan" -fd "/Users/michaelbyrne/cluster.mfb" -fUCCI

eng vs eng

[Event "Mac Pro x5690 3.46 Ghz 18 CPU"]
[Site "Mac-Pro.local"]
[Date "2017.11.03"]
[Round "-"]
[White "Stockfish 031117 64 POPCNT (UCI2WB)"]
[Black "Stockfish 031117 64 POPCNT (UCI2WB)"]
[Result "1/2-1/2"]
[TimeControl "10+1"]
[Variant "seirawan"]
[Annotator "1. +0.70   1... -0.38"]
1. e4 {+0.70/14 +9} Nc6/H {-0.38/15 +7} 2. Nf3/E {+0.45/17 +7} e5
{-0.12/16 +5} 3. Bc4/H {+0.13/17 +3} Nf6 {+0.09/16 +6} 4. d4 {-0.23/17 +2}
Nxe4 {+0.67/16 +6} 5. Nxe5 {-0.93/18 +1} Qf6/E {+6.07/17 +6} 6. Ef3
{+2.15/17 +1} d5 {-2.30/19 +4} 7. Exf6+ {+2.27/15 +2} Nxf6 {-2.26/20 +4} 8.
Be2 {+2.24/19 +1} Bd6 {-2.26/18 +4} 9. Nxc6 {+2.22/19 +1} bxc6
{-2.09/18 +4} 10. Nc3 {+2.20/16 +2} O-O {-1.96/19 +3} 11. Hd2 {+1.92/20 +1}
c5 {-1.96/19 +2} 12. dxc5 {+2.06/18 +1} Bxc5 {-1.90/18 +3} 13. O-O
{+2.16/17 +1} Hd7 {-2.05/20 +2} 14. Bd3 {+2.04/18 +1} Re8 {-2.10/18 +1} 15.
Hf3 {+2.25/15 +1} Bb7 {-2.05/17 +1} 16. Nb5 {+1.91/18 +1} Rc8 {-2.26/18 +1}
17. Bd2 {+1.99/17 +1} d4 {-1.87/17 +1} 18. Hh4 {+1.75/19 +1} Be4
{-1.64/17 +2} 19. a4 {+1.80/20 +1} Ec6 {-1.62/19 +1} 20. h3 {+1.68/18 +1}
Rb8 {-1.52/19 +1} 21. Hg3 {+1.80/19 +1} Bxd3 {-1.23/19 +1} 22. cxd3
{+1.16/18 +1} Nd5 {-1.07/18 +1} 23. Qb3 {+1.49/17 +1} Ef6 {-0.67/17 +1} 24.
Qd1 {+0.67/17 +1} Eg6 {-0.14/18 +1} 25. Hh5 {+0.24/18 +1} Hxh3+
{-0.05/19 +1} 26. Kh2 {-0.03/19 +1} Hf5 {+0.00/19 +1} 27. Hxg6
{+0.08/17 +1} Hxg6 {+0.15/18 +1} 28. Rc1 {+0.00/20 +1} Bb6 {-0.20/16 +2}
29. Qb3 {+0.00/19 +1} Re2 {-0.01/19 +2} 30. Qxd5 {+0.00/20 +1} Rxd2
{+0.00/18 +3} 31. Kg1 {+0.00/21 +1} Hf4 {+0.00/21 +3} 32. Qd7 {+0.00/22 +1}
He2+ {+0.00/19 +3} 33. Kh1 {+0.00/21 +1} Hxd3 {+0.00/24 +3} 34. Nxa7
{-0.15/24 +1} Bxa7 {+0.00/23 +3} 35. Qxc7 {+0.00/24 +1} Rf8 {+0.00/28 +3}
36. Qxa7 {+0.00/25 +2} Rxf2 {+0.00/31 +4} 37. Rxf2 {+0.00/29 +1} Hxf2+
{+0.00/32 +4} 38. Kh2 {+0.00/1 +2} Hg4+ {+0.00/34 +4} 39. Kh1 {+0.00/32 +2}
Hf2+ {+0.00/37 +2} 40. Kh2 {+0.00/1 +3} Hg4+ {+0.00/38 +1} 41. Kh1
{+0.00/32 +2} Hf2+ {+0.00/39 +2} 42. Kh2 {+0.00/1 +3} Hg4+ {+0.00/42 +1}
43. Kh1 {+0.00/45 +3} Hf2+ {+0.00/34 +1} 44. Kh2 {+0.00/1 +4} Hg4+
{+0.00/42 +1} 45. Kh1 {+0.00/48 +4} Hf2+ {+0.00/37 +1} 46. Kh2 {+0.00/1 +5}
Hg4+ {+0.00/44 +1} 47. Kh1 {+0.00/49 +4} Hf2+ {+0.00/38 +1}
{XBoard adjudication: repetition draw} 1/2-1/2

3,597 6-ply openings

uci
setoption name MoveScoreRange value 80
setoption name DepthFactor value 90
setoption name MultiPV value 5
ucinewgame
position startpos
setoption name threads value 12
generate 6 movetime 1000

https://www.dropbox.com/s/5uhybtnx7nyuw7w/Seirawan-6-ply%20openings-3597.epd?dl=1

[HGMuller]

The time losses seem to be my fault; I had not switched off move animation. With most engines that is not yet a problem at 40 moves/min, but Stockfish sometimes only leaves less than 1 sec for 5 moves, and then the accumulated animation time of the moves would push it through the clock.

It turns out there is a problem with S-Komodo, regarding to reading startposition FENs. It always assumes it has an E & H in hand. As some of the positions have the E & H already on the board, it will make illegal moves in games starting from those positions, by dropping pieces it does not have. And if the opponent started with E or H on the board it will make unsound sacrifices for pieces on the baseline to destroy the gating possibilities for the pieces it thinks the opponent still has in hand. Isn't it possible to have the opening lines in PGN form, rather than EPD form?

One final point: the presence of the UCI_Chess960 option confuses UCI2WB, which thinks that it also plays Chess960, (also implying orthodox Chess), which in fact is not the case.

[ianfab]

@HGMuller Yes, Stockfish's aggressive time management often causes issues like that in different setups.

Rewriting the book generator to output PGNs should be feasible, but it is not trivial as it currently only keeps the FENs in memory and not the moves, so I will probably not have the time to do that soon. But it anyway is a good feature suggestion, not only for this specific case. For now, a simple solution might be to just filter out the positions where a piece has already been gated, e.g., by doing a grep for [HEhe] on the EPD.

I have tried to not break 960 for the Seirawan chess implementation, but regarding the castling rights and gating squares in the FEN it probably currently does not work. Does Xboard support 960 for variants? And is it just misleading that chess and chess960 are shown as options or does it cause immediate issues? As Seirawan chess is a superset of orthodox chess, it should in principle also not be that difficult to reintroduce the possibility of playing standard chess (only changing the FEN format and the promotion options), but I currently do not plan to do that for simplicity.

[ianfab]

@HGMuller I filtered out all positions where a piece has already been gated, so the following book should work with Komodo: seirawan_allinhand.epd.txt

[HGMuller]

Good idea about the grep. I don't know if their will be any surprises with S-Komodo; it might not understand the virginity field of the XBoard FEN. OTOH, it then probably will assume all back-rank pieces are virgin. I will check if it does strange things.

As to Chess960: XBoard allows you to play any variant as shuffle game. There is a "New Shuffle Variant" menu where you switch the shuffling on. Depending on which type of castling you select (orthodox, Fischer or none) it will decide whether and how to involve King and Rooks in the shuffle. The engine does not have to know anything about this; it is the GUI that picks the start position, and sends it to the engine. That Fischer castling is allowed follows from the presence of castling rights in the FEN, and the location of the King and Rooks. Currently the user has to decide whether the engine can handle Fischer castling.

I guess we need a better definition of what the UCI_Chess960 option means in UCI. Does it mean that is plays the variant Chess960 (even though there is a UCI_variant option that does not list 'Chess960' as a possible setting, or only lists 'Chess')? Or does it mean the engine understands Fischer castling in all of the variants it does list? The latter interpretation is probably more useful. (But alas, not what UCI2WB currently assumes.) 'Chess960' would then become a redundant value for the UCI_Variant option; it should be played by setting that option to 'Chess', and then enabling the UCI_Chess960 option. The only effect on the engine is how it would encode castling moves, however (e1g1 vs e1h1 for O-O). We might as well specify that a GUI that is so audacious as to enable UCI_Chess960 should understand both. From the POV of the engine there only is doubt when the King and Rook are in the conventional places; in all other cases it must be Fischer castling, and the KxR encoding should be used.

The only bad thing that currently happens, is that XBoard allows the user to select variant 'normal' and 'FRC when Seirawan-Stockfish is loaded through UCI2WB, while strange things will happen when he actually selects those. When selecting 'normal' Stockfish will gate pieces anyway, when he selects Chess960 Stockfish will start with a move for black! I am particularly puzzled about the latter; XBoard would use a start-FEN in a shuffle variant as there is no agreed-upon start position that the engine could know. But a Chess960 FEN should be compatible with Seirawan Chess, with just nothing in hand (because the hand field is missing from the FEN). The problem in normal Chess is probably that UCI2WB uses 'startpos', thinking that it means something different than the engine thinks it means.

[HGMuller]

It seems to work. One catch already: Stockfish overlooks a mate in 1 here!

[Event "Computer Chess Game"] [Site "MAKRO-PC"] [Date "2017.11.03"] [Round "8"] [White "Schess64 12.0002 (UCI2WB)"] [Black "Stockfish 011117 64 (UCI2WB)"] [Result "1-0"] [TimeControl "40/60"] [Variant "seirawan"] [FEN "r1bqkbnr/pppppppp/2n5/6B1/3P4/8/PPP1PPPP/RN1QKBNR[HEhe] b KGFDBQkgfdcq - 0 1"] [SetUp "1"]

{-------------- r . b q k b n r p p p p p p p p . . n . . . . . . . . . . . B . . . . P . . . . . . . . . . . . P P P . P P P P R N . Q K B N R black to play --------------} 1... d5 {+0.19/15 3} 2. Nf3 {+0.12/11 1.1} Bf5/E {+1.07/13 1.0} 3. c4 {+0.15/11 2.2} Nf6/H {+1.11/17 7} 4. Nc3 {+0.36/10 1.5} Ne4 {+0.17/17 4} 5. Bd2 {+0.27/11 2.1} e5 {+1.27/13 1.1} 6. dxe5 {+1.17/10 1.0} d4 {+1.02/16 2.1} 7. Nxe4 {+0.78/10 1.0} Bxe4 {+0.27/15 2.4} 8. a3 {+0.74/11 4} f6 {+0.91/13 1.6} 9. exf6 {+1.15/11 1.5} Qxf6 {+1.07/14 2.1}

10. Rc1/H {+0.87/10 1.3} a5 {+0.17/15 1.8} 11. h4 {+0.83/10 0.9} h6 {+0.45/14 0.9} 12. Be3 {+1.02/11 1.1} Bxf3 {+2.44/15 1.3} 13. gxf3 {+1.11/11 1.3} dxe3 {+3.65/14 0.5} 14. Qd7/E# {+1000.01/1} {Xboard adjudication: Checkmate} 1-0

[ianfab]

@HGMuller Thanks. It is reproducible, see below. It might be related to a known hash bug I did not have time to fix yet, but I'll check later.

position fen r1e1kbhr/1pp3p1/2n2q1p/p7/2Pp3P/P3BP2/1P2PP2/H1RQKB1R[E] b KFDkq - 0 13
go depth 12
info depth 1 seldepth 1 multipv 1 score cp 448 nodes 56 nps 56000 tbhits 0 time 1 pv d4e3 f2e3
info depth 2 seldepth 2 multipv 1 score cp 448 nodes 111 nps 55500 tbhits 0 time 2 pv d4e3 f2e3
info depth 3 seldepth 3 multipv 1 score cp 462 nodes 169 nps 84500 tbhits 0 time 2 pv d4e3 f2e3 a5a4
info depth 4 seldepth 6 multipv 1 score cp 252 nodes 1241 nps 310250 tbhits 0 time 4 pv c8e7 d1c2e d4e3 f2e3
info depth 5 seldepth 5 multipv 1 score cp 239 nodes 1756 nps 351200 tbhits 0 time 5 pv f8c5 e3d2 c8e7 d1b3 c5b6
info depth 6 seldepth 8 multipv 1 score cp 340 nodes 2442 nps 348857 tbhits 0 time 7 pv d4e3 b2b3 f8a3 a1f6 g8f6 f2e3 c8e7
info depth 7 seldepth 8 multipv 1 score cp 310 nodes 5787 nps 413357 tbhits 0 time 14 pv d4e3 f1g2e f8c5 f2e3 c8d8 f1d2 d8e6
info depth 8 seldepth 11 multipv 1 score cp 274 nodes 8689 nps 413761 tbhits 0 time 21 pv d4e3 f1h3e f8c5 h3d7 e8f8 f2e3 c8e7 d7c6 f6c6
info depth 9 seldepth 12 multipv 1 score cp 292 nodes 21915 nps 608750 tbhits 0 time 36 pv d4e3 d1a4e c8b6 d1e3 f8e7 b2b3 b6a4 a1f6 g8f6 b3a4 e8g8
info depth 10 seldepth 12 multipv 1 score cp 294 nodes 29549 nps 720707 tbhits 0 time 41 pv d4e3 d1a4e c8b6 d1e3 f8e7 b2b3 b6a4 a1f6 g8f6 b3a4 e8c8 c1d1
info depth 11 seldepth 18 multipv 1 score cp 355 nodes 71369 nps 1049544 tbhits 0 time 68 pv d4e3 f2e3 f8d6 f1h3e c8e7 h3g4 a8d8 d1c2 d6c5 e3e4 f6f4 g4f5
info depth 12 seldepth 17 multipv 1 score cp 350 nodes 140038 nps 1250339 tbhits 0 time 112 pv d4e3 f1h3e e3f2 f1f2 c8e7 f2e4 a8d8 d1c2 e7e4 c2e4 g8e7 e1g1 f6h4 e4h4 e7h4 a1c2 f8c5 e2e3
bestmove d4e3 ponder f1h3e

[HGMuller]

I finished a match of 100 (40/1') games, from the first 50 EPDs. Stockfish won that with 60.5-39.5 (59+ 3= 38-). These are the games:

Seirawan1.pgn.txt

A noticible strategy difference is that Stockfish gates its Hawk and Elephant very early, while Komodo tries to postpone this, to keep its options open. In Fairy-Max I also gate as quickly as possible, but that is to mask the shortcoming that it does not keep track of gating possibilities, and would run the risk of not being able to gate in some of the pieces when it would be allowed to postpone it. So I give it a significant bonus for gating. (Which is equivalent to making the PST for pieces in hand quite low.) I guess the most logical approach would be to value a piece in hand slightly lower than on the board, but award a bonus for the number of gating options you still have. (A sort of mobility bonus.) E.g. when you have 3 virgin pieces on the back rank, and 2 pieces in hand, you can gate in 6 different ways. With 1 piece in hand that would only be 3. With 2 virgin pieces and 2 in hand you would still have 2 ways you could gate them in.. But I suppose that having as many virgin pieces as pieces in hand deserves a hefty vulnarability penalty. And of course having fewer virgin pieces loses you the full value of one or two pieces in hand.

And of course you would have to correct the number of virgin pieces for the fact that you want to castle. With just a virgin Rook and King left, and two pieces in hand, you are in dire straits, as you can now only gate them in by refraining from castling. So a virgin King doesn't fully count if there are still two pieces in hand.

I guess the best implementation would be to simply have a table with scores that you index by the 8-bit 'virginity mask' of the pieces on the back rank, and the hand content (256x4 = 1K entries). The bonus for having castling rights can be incorporated in that. In fact this whole thing is just a generalization of treating castling rights.

[HGMuller]

It is also interesting that Stockfish and Komodo often have very different evaluations (250-300 cP), both thinking they are ahead. E.g. in the following game Komodo is at +1.88, while Stockfish thinks it is at +0.66, without any reason I can see (and loses).

[Event "Computer Chess Game"] [Site "MAKRO-PC"] [Date "2017.11.04"] [Round "15"] [White "Stockfish 011117 64 (UCI2WB)"] [Black "Schess64 12.0002 (UCI2WB)"] [Result "0-1"] [TimeControl "40/300"] [Variant "seirawan"] [FEN "r1bqkbnr/pppppppp/2n5/8/1P4P1/8/P1PPPP1P/RNBQKBNR[HEhe] b KGFDCBQkgfdcq - 0 1"] [SetUp "1"]

{-------------- r . b q k b n r p p p p p p p p . . n . . . . . . . . . . . . . . P . . . . P . . . . . . . . . P . P P P P . P R N B Q K B N R black to play --------------} 1... Nxb4 {+0.80/13 7} 2. Nc3/E {+0.60/20 33} Nc6 {+0.79/13 8} 3. Bg2/H {+0.21/18 20} e6 {+0.95/13 7} 4. e4 {+0.91/18 31} h5 {+1.03/12 5} 5. gxh5 {+0.77/16 7} Nf6 {+0.97/12 6} 6. d4 {+0.37/14 3} d5 {+1.10/13 6} 7. He2 {+0.07/16 7} dxe4 {+2.03/12 6} 8. Nxe4 {+0.34/16 7} Nxd4 {+2.49/12 6} 9. Ed2 {-1.68/18 7} e5 {+1.93/12 7} 10. c3 {-2.27/20 26} Bh3 {+1.93/11 5} 11. Nxh3 {+0.27/17 2.1} Nxe2 {+2.19/13 8} 12. Exd8+ {+0.56/17 0.8} Rxd8 {+2.18/13 5} 13. Qxe2 {+0.51/20 12} Ba3/H {+2.19/13 7} 14. Bg5 {+1.09/18 4} Be7 {+2.40/14 6} 15. Ng3 {+0.26/19 11} He6 {+2.48/13 6} 16. O-O {+0.57/17 2.1} Hg4 {+1.88/14 23} 17. f3 {+0.66/20 8} Hd7 {+1.65/14 11} 18. Rad1 {+0.63/18 7} Hb6+ {+1.73/14 12} 19. Nf2 {+0.75/19 2.1} Nxh5 {+1.85/13 4} 20. Be3 {+0.04/23 24} Nxg3 {+1.88/15 8} 21. hxg3 {+0.00/22 5} Rxd1 {+1.93/15 5} 22. Rxd1 {+0.00/22 1.5} Hc8 {+1.81/15 10} 23. Rd5 {+0.28/21 1.7} Hf5 {+2.74/14 5} 24. Bf4 {+0.40/20 2.8} f6 {+3.17/15 6} 25. Rd1 {+0.94/23 27} Kf8/E {+3.99/16 5} 26. g4 {-2.82/24 5} Hh4 {+4.13/19 7}

27. Be3 {-2.72/23 3} Hg3 {+4.07/17 4} 28. Bf1 {-2.82/18 0.3} Hxe2+ {+4.10/17 9} 29. Bxe2 {-2.79/20 1.9} Eb8 {+4.19/18 15} 30. Bb5 {-3.16/22 8} a6 {+4.20/17 10} 31. Ba4 {-2.60/18 1.1} g6 {+3.98/16 7} 32. Ba7 {-2.67/20 3} Ec8 {+4.04/15 5} 33. Be3 {-2.89/17 0.5} Kg7 {+4.37/16 4} 34. Kg2 {-2.95/19 3} Rd8 {+4.19/15 2.9} 35. Rh1 {-2.84/21 2.6} c5 {+4.17/16 5}
28. Bh6+ {-3.45/22 8} Kf7 {+4.34/16 3} 37. Bc1 {-3.78/21 5} Rh8 {+4.53/15 4} 38. Rd1 {-3.82/19 1.5} c4 {+4.66/16 6} 39. Bc2 {-3.84/17 0.5} b5 {+4.60/15 8} 40. a3 {-3.65/17 0.5} Rh7 {+5.03/15 7} 41. Nh3 {-6.50/32 4:37} Rh4 {+5.12/16 6} 42. Bd2 {-4.51/16 0.5} Eh8 {+5.97/17 7}
29. Rh1 {-6.45/22 1.6} Bxa3 {+6.31/16 6} 44. Be1 {-6.84/18 0.4} Rh7 {+6.38/17 6} 45. Bg3 {-7.24/21 5} Kg7 {+6.35/17 7} 46. g5 {-7.25/19 1.0} Bb2 {+6.62/18 6} 47. gxf6+ {-7.45/19 0.8} Kxf6 {+6.77/15 1.3} 48. Be1 {-7.36/20 3} a5 {+7.32/16 7} 49. Bd2 {-7.91/20 2.0} Kg7 {+7.46/16 7} 50. Be4 {-8.39/20 2.4} a4 {+8.12/16 16} 51. Bc2 {-8.50/19 0.6} a3 {+8.75/16 6}
30. Bb1 {-8.68/18 0.4} Rh5 {+8.91/17 7} 53. Ba2 {-8.42/15 0.1} Ef7 {+9.45/16 7} 54. Bb1 {-8.22/17 0.3} Ea7 {+9.92/16 8} 55. Be3 {-10.08/19 2.1} Ea4 {+11.65/16 11} 56. f4 {-10.03/16 0.8} Exc3 {+15.19/15 5} 57. Re1 {-9.59/15 0.1} Rxh3 {+18.95/16 28} 58. Kxh3 {-21.43/16 0.6} exf4 {+20.93/14 1.5} 59. Bf5 {-67.24/18 1.1} gxf5 {+1000.11/14 26} 60. Rg1+ {-1000.10/20 0.2} Kf6 {+1000.09/9} 61. Rg3 {-1000.08/22 0.1} fxe3 {+1000.08/6} 62. Kh2 {-1000.06/20 0.1} a2 {+1000.07/4} 63. Rg1 {-1000.05/25 0.1} Ee2+ {+1000.06/2} 64. Rg2 {-1000.04/28} Be5+ {+1000.05/1} 65. Kh3 {-1000.03/63 0.1} Ef4+ {+1000.04/1}
31. Kg3 {-1000.03/63 0.1} a1=Q {+1000.03/1} 67. Rf2 {-1000.02/67 0.1} exf2 {+1000.02/1} 68. Kh2 {-1000.01/1} f1=E# {+1000.01/1} {Xboard adjudication: Checkmate} 0-1

[ceebo]

It seems to work. One catch already: Stockfish overlooks a mate in 1 here!

The problem could be that SEE thinks that the move Qd7/E# just loses a queen for nothing and so it is simply pruned in QS and low depth search.

[HGMuller]

I now did 100 games at 40/5', but the results should not be taken too serious, as it turns out my testing setup was buggy. For one, it turned out that UCI2WB did not handle start positions where black is to move correctly in combination with classical TC. In WinBoard (and I suppose most GUI), 40 moves/min from a black-to-move start position means that white already gets the time for his next session after 39 moves. UCI2WB was expecting this after 40, and thus sent the engine 'movestogo 1' for the 40th move, in combination with the time on the GUI clock, which had already received the new time slice. On one occasion this caused Stockfish to use op 299.9 sec of his third time slice for move number 120, to discover on the next move that it now had to play 40 moves in 0.1 sec. Not very good for its results, I imagine, even if it does manage to do that. I am now running a match where this is fixed.

Second problem is that there seem to be illegal moves. I suspect this is WinBoard's fault. because it seems to accept the illegal moves from the engine, but refuses them when I let it read back the PGN. So I suppose the engine actually did send the correct move, but WinBoard parsed it incorrectly, and then sent an incorrect move to the opponent (which then often got so upset that it played an illegal move itself, e.g. moving for the opponent, and got forfeited because of that). This happens for castlings with gating at the Rook square; these end up in the PGN as Rxd1/E instead of Rxe1/E. I was not making a debug log, so I cannot check what actually went on between GUI and engine; I am trying that now in my next test. So for now ignore the games with illegal moves.

Seirawan2.pgn.txt

[ianfab]

@HGMuller Thanks for the tests and analyses. Unfortunately, I did not have time to reply earlier, so I will now try to answer to the last couple of posts, hoping I have not overlooked something.

• Regarding the UCI_Chess960 option, I think it would make sense to have it as a general option not coupled to standard chess, otherwise we would need a separate 960 variant name for each variant (atomic960, giveaway960, ...).
• That it moves for black in the starting position if you select chess960 is due to a not very resilient FEN parsing. From the code I assume that the same should happen for the crazyhouse implementation in this repository, but I have not checked it in detail. I will try to make the FEN parsing more robust.
• I had a quick look at the mate in 1 position, but it is not clear to me yet whether this is caused by the transposition table, SEE pruning, or something else. I'll have to investigate.
• The close result in the first match is interesting. I did not have a guess which engine would win, but I expected that the result would not be close, since it is likely to have a big difference in playing strength if not much time has been put into optimizing play for a variant.
• The reason for the early gating by Stockfish is that I introduced a malus for having pieces in hand depending on the number of gating possibilies that are left, see https://github.com/ianfab/Seirawan-Stockfish/commit/613c95cd361190d957753a294051b49a6bf48740. This ensures that it does not "forget" to gate the hawk and elephant, because if it runs out of gates the evaluation will be as if it would not have any pieces in hand. It is of course a very simple approach (just to avoid obvious blunders), and it will be interesting to find out which strategy will turn out to be the best for the timing of gating.

[HGMuller]

• OK, so let us define the presence of the UCI_Chess960 option to mean that the engine understands Fischer castling in any variant (with castling) that it supports, and not that it actually plays Chess960 if the UCI_Variant option does not have 'chess' as a possible value. Enabling the option should make the engine send castling moves in 'bestmove' and 'info pv' commands in the KxR format even when the King and Rook are in their normal position; when the latter is not the case it should ALWAYS send Fischer castlings in KxR notation. If the option is disabled the engine should use the King step when the pieces are in their standard location (e1g1 etc.). The setting of the option should not affect the engine's ability to perform Fischer castling, or its ability to parse Shredder FEN; the right to make a Fischer castling should purely follow from the FEN it received in the 'position' command.
• From the games I got the impression Stockfish often gets taken by surprise when Komodo makes a gating moves, getting a large score jump, which makes its score converge to that of Komodo.
• Gating strategy is interesting. I got the impression that Stockfish is too hasty, and Komodo too tardy. One conventional piece of Chess wisdom for the opening phase is "develop the Knights before the Bishops". This is often explained by that there is usually very little choice as to where Knights must go, but a lot of choice for Bishops, and you want to keep your options open. If you commit yourself too early, the opponent will be able to exploit that, by playing the counter strategy that is optimal for the line you committed too. I suppose the same holds here. But gating onto the board does count as developing the piece, so you don't want to postpone it too much. Just until after you did the more urgent development. Also worth noting is that potential Bishop development moves have 'more punch' when you have a Hawk in hand, while Queen moves have more punch with an Elephant in hand. It might not be possible to tune this in game play; it is really a book-building matter.

[ceebo]

@ianfab wrote:

I had a quick look at the mate in 1 position, but it is not clear to me yet whether this is caused by the transposition table, SEE pruning, or something else. I'll have to investigate.

I had a further look at why the move Qd7/E was disappearing. SEE pruning is definitely not helpful but probably a more serious problem is that gating moves are not considered pseudo_legal because of non-zero bits in the promotion flag.

If a gating move is the ttMove then Movepicker will set the ttMove to MOVE_NONE and the move can still get looked at later. That's not ideal.

More serious is that if a gating move is a killer move then there is no opportunity for it to be played at all.

[ianfab]

@ceebo Thanks a lot. Your explanation sounds logical and it perfectly matches the observed behavior.

[HGMuller]

Just out of curiosity, since we have been talking about Seirawan960: Would your implementation of hand pieces also allow other pieces than Elephant and Hawk to be in hand, e.g. a Queen? When shuffling the initial position it would be logical to involve the hand as well. Perhaps not for weak pieces, but certainly for the Queen. So not make it Seirawan960, but Seirawan2880, because there are 3 ways to choose the super-piece that starts on the board. WinBoard does allow this type of shuffling (by putting a '?' for the piece on the board in the startup FEN, and QEH in the hand).

[ianfab]

@HGMuller The current implementation does not support gating of other pieces than hawk and elephant. In principle it should not matter which piece is gated, but the problem is that in order to make the move encoding fit into 16 bit (for TT) I had to make assumptions about the piece types that can be gated. Since two bits (the promotion piece type bits) are currently used for that, but only 3 possibilities are used (none, hawk, elephant), it should be possible to add a fourth one, i.e., the queen, although the move encoding would get even more ugly than now. Adding more than that (i.e., rook/bishop/knight) is most probably impossible without adding bits to the move encoding and hence messing up the TT.

However, as mentioned before, the Seirawan960 implementation probably anyway does not work at the moment due to issues with the castling and gating flags, but I have not tested it yet.

[HGMuller]

I played another 100 40/1' games, this time with proper time control. This time I saved the debug log for the entire match. Four games were messed up by WinBoard when a castling with gating at the Rook square occurred. (It prints those with the d1/d8 square as destination, rather than e1/e8; such an illegal move sent to the engine leads to Komodo moving e1c1 without thinking, and Stockfish to move for the opponent.) It forfeited both Stockfish and Komodo each twice for this. There was one genuinely illegal move by Komodo. (A castling with gating at the Rook square while there was a Hawk between King and Rook!)

Five games were lost by Stockfish on time, all close to the end of a session. In three cases the position seemed lost anyway; in two cases it was a dead draw.

The total result was 65.5% in favor of Stockfish (62+, 7=, 31-). These are the games:

Seirawan3.pgn.txt

[ianfab]

I have commited two changes to fix the bug in pseudo-legal move validation (thanks again @ceebo) and to improve SEE in order to avoid pruning good gating moves. The first commit helps to find the mate in 1 blunder much earlier and after the second commit it is already found/avoided at depth 1. I have not done that much testing, but the performance in self-play does not look bad.

FEN parsing should be more robust now and allows to skip the brackets for pieces in hand, so it should also support standard chess FENs and play legal moves. I applied similar changes to crazyhouse, see #439.

[HGMuller]

Ah, I see. WinBoard contains a patch to correct engines that send castling in KxR format in games without Fischer castling. For King-side castling this corrects e1h1 to e1g1, by shifting the to-square one step left. (This to prevent the KxR format will be sent to the opponent, which likely would choke on it.) Unfortunately it also applies this to the RxK format of Seirawan Chess gating-at-rook-square castlings, as in general Seirawan Chess does not have Fischer castling. This way h1e1 gets 'corrected' to h1d1. But only when received from an engine. I should exempt castlings with the King on the to-square from this pre-processing.

The current treatment of gating-at-rook-square castlings is unsatisfactory anyway, as these now show up in PGN as Rxe1/E, which is absolutely ugly. I guess an alternative would be to use O-O/E with a file disambiguator on the gating suffix, like O-O/Eh vs O-O/Ee. I don't like that very much either. How about O-O\E vs O-O/E?

[ianfab]

@HGMuller O-O\E vs. O-O/E might also be confusing. How about something like O-OR/E vs. O-O/E? Or is this problematic for parsing?

[ddugovic]

If there's a move list, how can the move be written without confusing the spectator?

[HGMuller]

I don't like the O-OR/E so much. It is not in the spirit of SAN, because it assumes a default (i.e. the other one is not O-OK/E), and using piece names to disambiguate moves is unprecedented. If an extra letter is to be used the file ID would be more in the style of SAN, so O-O/Eh vs O-O/Ee. Since the difference concerns where the gated piece appears, and not how the castling itself is performed, it seems to be more logical to indicate it behind the slash.

[alwey]

would be more in the style of SAN, so O-O/Eh vs O-O/Ee

This is what I would expect for SAN disambiguation. I suggest O-O/E notation would default to O-O/Ee. On the interface the engines will transmit h1e1h and h1e1e?

[ianfab]

Yes, O-O/Eh is perhaps the most consistent with SAN.

I would suggest to keep the engine interface as it is.