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:
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.
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.
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.
@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.
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.
@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}
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.
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
@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.
@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.
@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.
@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.
@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.
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
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.
@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](https://github.com/ddugovic/Stockfish/issues/423#issuecomment-336521087) where your feedback would be very much appreciated.]
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.
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.
So far I've registered with Appveyor #351 but have not figured out how to configure those Windows builds to enable variants.
Dann Corbit : http://www.talkchess.com/forum/profile.php?mode=viewprofile&u=58
could probably do that.
@hgmuller - his name is Frank Cammarata, a very nice man and a smart businessman.
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"]
@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.
I can try to merge Seirawan into the book generator and if successful will post opening book.
@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.)
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.)
@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?
@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
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
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.
@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.
@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
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.
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}
@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
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:
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.
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}
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.
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.
@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.
@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.
@ceebo Thanks a lot. Your explanation sounds logical and it perfectly matches the observed behavior.
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).
@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.
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:
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.
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?
@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?
If there's a move list, how can the move be written without confusing the spectator?
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.
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?
Yes, O-O/Eh is perhaps the most consistent with SAN.
I would suggest to keep the engine interface as it is.
Sure, I don't want to change the move format in the engine protocols. This is purely for in the PGN. Rxe1/E, what it does now, is just awful.
No change requested, I just asked stockfish, too.
On the interface the engines will transmit h1e1h and h1e1e?
It answered: yes ;-)
@HGMuller
Sure, I don't want to change the move format in the engine protocols. This is purely for in the PGN. Rxe1/E, what it does now, is just awful.
+1
FYI: I opened a PR for seirawan support in cutechess.
Comments, questions and suggestions are welcome.
@alwey That is awesome news.The PR sounds like there are no bugs/limitations, so have you managed to solve the issues you mentioned before?
By the way, I implemented Makruk (Thai chess) in Stockfish recently (again as a separate repository due to the fairy pieces). Makruk is not very different from Shatranj, so starting from a similar implementation was much less work, but still a bit tricky due to the promotion on the 6th rank and the "silver general" moves.
How are you going to handle the counting rules? Do you think they are important for an engine, which would try to win in the shortest possible number of moves anyway? Should the engine just be biased against capturing the opponent's last Pawn?
@HGMuller I am not sure. For now I left them out for simplicity, because I think it would require an extended FEN to be able to fully support counting rules, but workarounds like the one you suggested are also an option or to only support them for positions where the move history is given with the position command. Do you know whether or how they are implemented in other Makruk engines?
@ianfab Thank you. There are certainly bugs in it, but none that I am aware of. Regarding the castling moves, the choices presented in the UI do not have special graphics for insertion at the rook square. Currently, the choice for gating at a rook square is presented to the left of the respective choice for gating at the king square. I was too lazy to change this and I trust the community to make suggestions.
I would like to finish the work on shatranj and courier.
I implemented Makruk (Thai chess) in Stockfish recently
Great to hear, I just cloned and compiled it. I will use the Makruk-Stockfish with _Xboard_ and _PyChess_. Makruk for Cutechess is something I would like to attack in 2018. Currently, among others, I have branches for Grand Chess and Alice Chess. For the latter I am using _Looking Glass 4.8S_ by @HGMuller for testing.
So far the award for most difficult implementation (most stupid developer) goes to seirawan and me.
grand has been more work than the other variants but considerably less than seirawan. alice is a good candidate for causing headache, too.
@alwey It's amazing how many variants you have already implemented and are implementing. The progress of multi-variant Stockfish would certainly not be as fast if we could not use fishtest (i.e., cutechess) for some variants.
Alice chess sounds like a big challenge, but also like a lot of fun. Now that you mentioned it I am wondering if that could also be implemented in Stockfish. Not that I am going to implement it any time soon, but it would certainly be interesting to at least try it some time.
@HGMuller I thought a bit about how to deal with the counting rules and came up with the following idea:
With these changes only the case where a piece is captured after counting has started might be evaluated incorrectly, e.g., if the stronger side sacrifices a rook in K+2R vs. K. In order to avoid extending the FEN, one could increase the half move clock to take account of the changed upper limit. E.g., if the rook is captured in the above example, then we add 16 [= [16 (1R) - 8 (2R)] * 2 (half moves)] to the half move clock, so that the effective number of remaining moves is the same as if we would remember that counting started from a situation with two rooks. That would also make sure that transpositions from different endgames can easily be compared.
I am relatively new to Makruk (learned the rules a few days ago), so I do not have much knowledge about endgames. I have tried to incorporate knowledge about all basic endgames (including 3 met, ma+2 met, khon + ma, khon + met, etc.), but I basically had to make educated guesses and let Stockfish figure out the correct result by letting it solve them. Does anyone of you have a table of material configurations that are known wins/draws? I would also be interested to know which kind of endgames are very common or important in Makruk, e.g., something similar to rook and pawn endgames in chess.
I also do not know much about other Makruk engines. Does anyone have a rough estimate of the relative and/or absolute playing strength of Makruk engines? I only tested Stockfish against Sjaak II and fairymax, where Stockfish finished first slightly in front of Sjaak II.
A good way to present Alice Chess is to super-impose the boards, displaying pieces in the 'non-current layer' with a high degree of transparency. And as soon as the user clicks a piece, make the layer that contains it current.
@ianfab ; Thank you. I have been aware this (Multi Variant Stockfish) project for about 16 months now. I admit that together with lichess.org it has had a major influence and inspired my participation in the cutechess project. Other major influences are from Xboard, Fairymax, and Sjaak II, and the literature about variants and the history of chess. HGM.
@HGMuller:
A good way to present Alice Chess is to super-impose the boards, displaying pieces in the 'non-current layer' with a high degree of transparency.
Thank you. I think this is indeed a good way for presentation in the GUI. This will be
a thing to work on at a second stage. Currently, I am only using a plain board representation of 16 files and 8 ranks without any indentations, markings or eye guides (the A board is the left part, the B board the right part).
In the first phase I am trying to get the machine interface right, the legality of moves and positions, game adjudication, input/output of positions and game notation and a basic GUI representation. I am glad to have _Looking Glass_ to help me.
@ianfab : First light with Cutechess and Makruk:
Rank Name Elo +/- Games Score Draws
1 stockfish-mak-f364111 512 179 60 95.0% 10.0%
2 sjaakii-1.4.1 -53 78 60 42.5% 25.0%
3 sjaakii (1.3.1 xboard) -120 77 60 33.3% 30.0%
4 shamax-5.0b -154 86 60 29.2% 21.7%
120 of 120 games finished.
All games (30 s + 0.3 spm, 1 Thread on a core-i5 laptop) from starting position and with Shatranj adjudication rules. There were no duplicate games.
I had detected some issues within cutechess /wrt pieces with lower move symmetry, here Khon (Silver General) and found a provisional solution. This is not quite ready for the big stage.
@alwey Thanks. Looks like the evaluation improvements since the first version has given SF quite an edge over Sjaak. I can imagine that the asymmetric piece movements cause some issues. For SF that was luckily not that problematic as I could mostly simply copy&paste the logic from the pawns and only change the list of possible relative square differences. Would this be the first variant with asymmetric piece moves (apart from pawns) in cutechess?
@ianfab :
Would this be the first variant with asymmetric piece moves (apart from pawns) in cutechess?
Exactly. I must talk to Ilari and Arto about how we should generalise the move generation in the base classes.
Note that Ferdinand Mosca also made a Makruk engine (Bilis), and that his engines tend to be pretty strong compared to Fairy-Max and Sjaak II.
@HGMuller : Thank you for the hint. I got Bilis and indeed it turned out to be significantly stronger than Sjaak II and Fairy-Max:
Rank Name Elo +/- Games Score Draws
1 stockfish-mak-f364111 359 103 80 88.8% 15.0%
2 Bilis_v1.0 127 65 80 67.5% 32.5%
3 sjaakii-1.4.1 -61 60 80 41.2% 40.0%
4 fairymax-5.0b -174 62 80 26.9% 38.8%
5 NebiyuAlien -185 55 80 25.6% 46.2%
200 of 200 games finished.
Again, Tc = 30 s + 0.3 spm, 1 Thread. This time Standard Chess adjudication was used.
@ianfab : I implemented a solution for Khon move offsets without changes to the base classes, so I can move on to the next topic: adjudication rules.
I have implemented a first version of support for counting rules, but it can still be turned off via a UCI option. I have not made any evaluation adjustments yet, so it can only find the draw by resolving it in the search. In an example with two rooks (8/8/5k2/7p/8/6RR/3K4/8 w 0 1), it took about 0.1s for it to find that capturing the last pawn leads to a draw. For material configurations with higher move counts, that might not work that well.
Indeed, the draws will be very hard to recogize by search, as you
basically have to search every possible branch to the available number
of moves before you can conclude it is a draw. Any reduced branch would
still have the huge material advantage.
A first approximation would be to consider any end-game against a bare
King as drawish, and apply a hefty reduction to the score (like a factor
8). This should strongly bias the engine against capturig the last
piece, if it is significantly ahead in the presence of that piece.
End-games like KRPPKR could still be a problem, and allow f.e.
rabid-Rook defense because you canot afford to take the Rook. But in
general this would probably work much better than not discounting any
end-game at all.
Op 1/1/2018 om 6:40 PM schreef Fabian Fichter:
>
I have implemented a first version of support for counting rules
https://github.com/ianfab/Makruk-Stockfish/commit/8ae928d54cd93492be9adb25f06e7b0e7a6f1974,
but it can still be turned off via a UCI option. I have not made any
evaluation adjustments yet, so it can only find the draw by resolving
it in the search. In an example with two rooks (8/8/5k2/7p/8/6RR/3K4/8
w 0 1), it took about 0.1s for it to find that capturing the last pawn
leads to a draw. For material configurations with higher move counts,
that might not work that well.—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ddugovic/Stockfish/issues/426#issuecomment-354665645,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AVNwNjDB-2XfA0XopdM3H2vtk7F8Gcd1ks5tGRikgaJpZM4P_yPM.http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient
Virus-free. www.avg.com
http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
@HGMuller Only reducing the evaluation for endgames against the bare king would not work well in Stockfish without applying further changes since it only follows the strategy of driving the king to the corner if the weaker side has no material left and for a few specific material configurations. So it would fail to make progress in situations like 2 khon vs. pawn (e.g., 8/8/5k2/7p/6SS/8/3K4/8 w 0 1) if it does not capture the pawn.
I have written an experimental change where the evaluations of positions against the bare king are scaled by "number of remaining half-moves in counting" / 128, and where the general "KXK" endgame evaluation function is also applied to cases where the weaker side still has a pawn or a met. This seems to work well even in cases where it can not resolve mate from the initial position, e.g., the aforementioned 2 khon vs. pawn. It first drives the king towards the corner and only takes the pawn as soon as it finds mate within the required number of moves. So the first results look good, but I have not done much testing yet.
I searched for an even stronger opponent than Bilis, so I tried Alisa which claims to be the strongest Makruk AI. I set up different levels in the browser (sharp and disciple) and mirrored the moves in XBoard to let it play against Stockfish (including https://github.com/ianfab/Makruk-Stockfish/commit/d782b1f970b0cc5f041f323f5b98a4a73edf69ef). I tried to use similar thinking times for Stockfish as it took for Alisa to make a move. The actual move times and https://trello.com/c/Ab465qHu/57-alisa-level suggest that the levels do not use any handicap except from the thinking time, but I do not know for sure. To take account of the speed handicap due to Alisa running with javascript in the browser, I gave Stockfish a time handicap in the last game, only using 10s for 40 moves, whereas the opponent used about 1s per move. To my surprise, Stockfish performed incredibly well and won all three games (all three playing white, since I did not find an option to play with black against Alisa in the browser).
Here is the PGN of the games:
stockfish-alisa.pgn.txt
In the opening, Stockfish's play looked a bit strange to me and it also was bad at predicting Alisa's opening moves. Starting from the middlegame Stockfish always seemed to outplay the opponent and usually correctly predicted the opponent's moves (apart from blunders).
I would take such claims with a grain of salt. I am not aware of any
Makruk championship for computers. And I don't recall having ever seen a
Makruk competition at the ICGA computer Olympiad. A Thai user of
Fairy-Max informed me that it would be the strongest Makruk program if I
could only equip it with EGT for some elementary end-games. I would not
believe a Thai program is stronger than Bilis without proof. Playing a
JavaScript demo probably doesn't mean anything, though.
I also could not find any engine match results, that is why I wanted to test it. Due to their claim I simply considered it as a interesting candidate to be tested, and I thought that a dedicated Makruk engine that seems to be actively developed might indeed be stronger than Stockfish, since I expect that for a strategic variant like Makruk evaluation is very important, and apart from choosing reasonable piece values (from my almost non-existent experience with Makruk) I did not change much of Stockfish's (not endgame-specific) evaluation code.
I of course can not be sure that the browser version is at full strength, but as I mentioned above the move times and the information I found kind of suggest that this might be the case and that the only limitation of the browser version is that the window of possible move times is restricted from above and below (out of 15 levels/move-times only 5 from the middle seem to be available). A lot of speculation of course, but at least I have the feeling that I have a rough idea of its playing strength, since I played one more game with more significant time handicap where Stockfish lost. Now I can move on to improving Stockfish (if I find the time).
Well, as chess variants go, Makruk is quite close to Chess (after tradig
Queens). So most of Stockfish' strategic insight should apply. Most
obvious difference is that Pawn promotion is hardly worth anything,
which reflects back on passer bonuses. The most important term in Pawn
evaluation seems to be the distribution over square shades of the
promotions. Having two Pawns that promote on different shades can often
be better than having 3 Pawns that promote on the same shade.
It is always good to have new opponents, but before spending too much
time on Alisa I would first make sure that it is stronger than Bilis,
otherwise it would just be a waste of time. The web version seemed to be
limited in thinking time (which might be of no importance for the TC you
like to test at). There does not seem to exist a native Windows version
of Alisa; what they advertize as such turns out to be a .apk file you
have to run on an Android emulator. I consider it a virtual certainty
that the Alisa developers don't even know Bilis exists, and that even
when they did, they would not bother to test against it. But perhaps I
am to skeptical.
But if Alisa is available in JavaScript, it is of course available in
source code, and it should be comparatively easy to equip it with a
standard engine interface, so it could be used in automatic testing.
Op 1/4/2018 om 11:53 PM schreef Fabian Fichter:
>
I also could not find any engine match results, that is why I wanted
to test it. Due to their claim I simply considered it as a interesting
candidate to be tested, and I thought that a dedicated Makruk engine
that seems to be actively developed might indeed be stronger than
Stockfish, since I expect that for a strategic variant like Makruk
evaluation is very important, and apart from choosing reasonable piece
values (from my almost non-existent experience with Makruk) I did not
change much of Stockfish's (not endgame-specific) evaluation code.I of course can not be sure that the browser version is at full
strength, but as I mentioned above the move times and the information
I found kind of suggest that this might be the case and that the only
limitation of the browser version is that the window of possible move
times is restricted from above and below (out of 15 levels/move-times
only 5 from the middle seem to be available). A lot of speculation of
course, but at least I have the feeling that I have a rough idea of
its playing strength, since I played one more game with more
significant time handicap where Stockfish lost. Now I can move on to
improving Stockfish (if I find the time).—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ddugovic/Stockfish/issues/426#issuecomment-355422483,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AVNwNkj_ufsZZDLNm8-i3Dt2J5s5n_eGks5tHVZzgaJpZM4P_yPM.http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient
Virus-free. www.avg.com
http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
I am quite confident that Stockfish already is about 200 elos stronger than Bilis 1.0 .
Score of Stockfish 030118 64 BMI2 vs Bilis_v1.0: 134 - 7 - 59 [0.818] 200
Elo difference: 260.49 +/- 44.80
There is a native Windows version of Alisa. The developer calls himself _peacedeveloper_ and older versions of Alisa can be found under different package names., e.g. _Peace Thai Chess Master_. This is a version from 2007:
ThaiChess/blackbox$ wine Alisa.exe
Alisa Black Box
- Alice Project -
by
Akkaradech Sujanil
[email protected]
http://www.peacedeveloper.cjb.net
------------------------------
Welcome to Alisa
------------------------------
uci
id name Alisa 1.02
id author Akkaradech Sujanil
uciok
ucinewgame
go movetime 1000
Need Registeration
@ianfab build & test processes started.
@ppigazzini Thanks.
The first tests for Seirawan chess and Shatranj after the worker update are looking good, so feel free to submit tests also for these variants. @ceebo Now that testing is more convenient and reliable, I will perhaps add a few regression tests for our previous development to check again that we did not introduce a regression anywhere.
@ianfab: Please note that cutechess-cli's ShatranjBoard is adjudicating draws after 70, not after 50 reversible moves
@alwey Thanks for the info. I saw it in your PR, but have not really kept it in mind. I do not have a preference for a certain number here since I guess no such rule (neither 50 nor 70) is historically known for Shatranj, so I will just adapt Stockfish to be consistent with the 70-move rule in cutechess.
@ianfab :The draw rate might drop a bit, because there are many slow-moving pieces.
The fifty-move rule of chess is derived from shatranj, which had a seventy-move rule. https://en.wikipedia.org/wiki/Fifty-move_rule#History
@alwey Oh, I didn't know that. In that case I will certainly change it to 70 moves.
May be it's time to challenge Yasser Seirawan to a 10 games in his variation :-)
Is there a site where one can play Seirawan chess vs Stockfish ?
If that doesn't exist, I will be glad to manually operate Stockfish in Winboard and send move on site.
Which site does support SChess ? I know some sites where one can play Crazyhouse960 and another one RelayChess ...
The Variant ICS (winboard.nl) supports S-Chess, an WinBoard can be used
as a client to play an engine on it.
Op 4/18/2018 om 10:12 AM schreef Vinvin20:
>
May be it's time to challenge Yasser Seirawan to a 10 games in his
variation :-)
Is there a site where one can play Seirawan chess vs Stockfish ?—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ddugovic/Stockfish/issues/426#issuecomment-382303072,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AVNwNhqGKkcSwoOBQTsE9OzIH9qjsKlXks5tpvV3gaJpZM4P_yPM.http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient
Virus-free. www.avg.com
http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
One point would be to promote Seirawan Chess with the help of Lichess broadcast.
But is it possible to do that ?
I don't think LiChess supports S-Chess (or any variant with unorthodox pieces).
winboard.nl works great (I've played on it before) especially using WinBoard/XBoard.
Pity that Tom's Live Chess Viewer (probably) doesn't support variants, so broadcast options (to reach the widest possible audience) would probably be to livestream the games.
TLCV is also a dedicated client that has to be downloaded first, just like WinBoard. So in principle there is not much difference between running the game on an ICS and using WinBoard as client to view the games, or using TLSC to relay games played through a GUI and using TLCV to view them. Except that, indeed, TLCV does not support variants. And is almost impossible to set up due to firewalls and such.
I guess that to really reach a large audience you would need to use a browser-based solution; many people dislike having to download dedicated clients. In fact I have been working on the development of such a client, using my turn-based server and its JavaScript/HTML client as a viewing agent. The broadcaster then simply uploads the game move by move to that server (using a special password that allows it to submit moves for both players).
Most helpful comment
FYI: I opened a PR for
seirawansupport in cutechess.Comments, questions and suggestions are welcome.