Winboard 4.8.0b and xiangqi engines

[Ferdy]

While working on xiangqi engine, encountered these games with winboard comments on engine behaviour.

Code: Select all

[Event "Computer Chess Game"]
[Site ""]
[Date "2016.06.18"]
[Round "26"]
[White "Makulit v1.0"]
[Black "HaQiKi D 1.8a"]
[Result "1-0"]
[TimeControl "120+1"]
[Variant "xiangqi"]
[Annotator "7. -0.01   6... +0.36"]

1. Ece2 Cbf7 2. Hc2 Hc7 3. Rb0 c5 4. Ca2 Ege7 5. Hi2 Hg7 6. g4 Afe8
{+0.36/12 4} 7. c4 {-0.01/14 6} cxc4 {+0.48/13 3} 8. Exc4 {-0.15/13 1.2} g5
{+0.40/13 4} 9. gxg5 {+0.11/13 4} Exg5 {+0.40/12 1.9} 10. Hd4 {+0.16/12 4}
Ce7 {+0.56/11 4} 11. Chc2 {+1.02/13 2.7} Cxe3 {+0.12/12 14} 12. Rh0
{+1.11/13 2.7} Rh9 {+0.24/11 2.1} 13. Rh6 {+1.02/13 2.9} Hd5 {-0.24/10 2.5}
14. Rb5 {+1.35/13 3} Hf4 {-0.56/11 2.2} 15. Rxg5 {+1.55/12 4} Hf9
{-1.04/10 8} 16. Rg4 {+1.60/11 4} He2+ {-1.12/10 2.2} 17. Afe1 {+1.47/12 4}
Hc1+ {-1.16/11 1.5} 18. Kf0 {+1.67/5 0.1} Hxa2 {-1.24/11 2.3} 19. Exa2
{+2.02/11 0.8} Ra7 {-1.20/11 4} 20. Ee2 {+1.98/11 2.7} Rf7+ {-1.72/10 2.7}
21. Ke0 {+2.26/13 3} Ee7 {-1.80/11 5} 22. i4 {+2.12/11 2.3} Cc3
{-1.92/11 17} 23. Hh4 {+2.09/12 3} Rg9 {-1.76/11 1.7} 24. Rxg9 {+1.92/14 3}
Exg9 {-2.00/11 1.8} 25. Rxe6 {+2.24/14 2.3} Rf4 {-2.08/11 4} 26. Hdf5
{+2.07/15 3} Cb7 {-2.16/10 2.2} 27. Rc6 {+2.94/13 2.6} Ce3 {-2.36/10 2.9}
28. Rc3 {+3.84/13 3} Ce6 {-3.04/11 2.5} 29. Rf3 {+2.36/14 3} Cb0+
{-2.88/12 1.4} 30. Ec0 {+2.47/18 3} Rc4 {-3.04/12 2.7} 31. Hh6 {+2.39/17 3}
Cb8 {-2.96/11 1.5} 32. Re3 {+2.55/16 2.0} Rxc2 {-2.52/13 2.6} 33. Rxe6
{+2.34/16 2.9} He7 {-2.56/13 1.3} 34. Rxa6 {+2.38/14 2.8} Rc6
{-2.68/13 1.3} 35. Rxc6 {+2.82/18 2.5} Hxc6 {-2.72/16 1.4} 36. Hxi6
{+2.77/19 2.7} Hd4 {-2.84/16 7} 37. Hh4 {+2.91/17 2.2} Cb3 {-3.00/14 2.7}
38. H4f5 {+2.93/17 2.7} Hf3 {-3.12/15 1.3} 39. Hd6 {+2.93/18 2.5} Hg1+
{-2.60/15 1.0} 40. Kf0 {+3.07/5 0.1} Cf3 {-2.64/15 1.1} 41. Hi8
{+2.93/17 1.8} Hh3 {-2.52/16 1.4} 42. Hc8+ {+2.92/18 2.6} Kf9 {-2.56/1 0.1}
43. Hg7+ {+2.78/18 2.5} Kf8 {-2.60/1 0.1} 44. Kf1 {+2.86/19 2.5} Cf6
{-2.64/14 1.1} 45. Hh5 {+2.88/17 2.5} Cf7 {-2.60/15 1.2} 46. Hd6
{+2.90/17 1.7} Hf4+ {-2.76/14 1.1} 47. Hf6 {+2.96/18 2.4} Kf9 {-2.84/15 5}
48. Hxf7 {+3.29/20 1.7} Axf7 {-2.88/15 1.9} 49. i5 {+3.27/20 2.2} Hg2
{-3.04/14 1.4} 50. He4 {+3.36/21 2.3} Ae8 {-3.12/14 1.9} 51. Hd6
{+3.43/20 2.3} Ad7 {-3.16/15 3} 52. ih5 {+3.48/21 2.2} Hh4 {-3.20/14 1.2}
53. Eg4 {+3.57/18 2.2} Hg2 {-3.12/14 1.0} 54. h6 {+3.55/18 1.8} Ee7
{-3.24/14 1.3} 55. Ece2 {+3.59/18 2.0} Hf4 {-3.40/14 1.2} 56. Hxf7
{+4.21/19 2.1} Hd3 {-3.84/16 3} 57. Af2 {+4.35/18 2.1} Ae8 {-3.92/15 1.7}
58. Hh8+ {+4.51/20 1.6} Ke9 {-3.96/15 0.8} 59. Hg6 {+4.62/20 1.6} Ec9
{-4.28/14 1.3} 60. h7 {+4.77/21 2.0} Kf9 {-4.12/13 1.5} 61. h8
{+4.91/19 1.6} Hb4 {-4.48/14 2.1} 62. Ae1 {+4.92/17 1.5} Ke9 {-4.60/13 0.9}
63. hg8 {+4.95/18 2.0} Hc2 {-5.00/14 1.8} 64. a4 {+5.08/17 1.8} Hd4
{-5.28/14 1.6} 65. a5 {+5.15/17 1.9} Hc6 {-5.40/14 1.2} 66. ab5
{+5.48/20 1.8} He7 {-5.72/14 1.2} 67. Hxe7 {+5.45/24 1.9} Exe7
{-6.40/17 1.3} 68. gf8 {+5.45/19 1.8} Ad9 {-6.28/18 1.0} 69. b6
{+7.85/20 1.5} Ae8 {-399.64/18 1.1} 70. bc6 {+9.29/19 1.3} Eg5
{-399.68/16 0.1} 71. c7 {+99.81/18 1.7} Ee7 {-399.72/14 0.1} 72. c8
{+99.87/18 1.3} Ec5 {-399.76/12 0.1} 73. cd8 {+99.89/18 1.8} Af7
{-399.80/10 0.1} 74. Kf0 {+99.91/19 1.2} Ee7 {-399.84/8 0.1} 75. Ke0
{+99.93/17 1.7} Ae8 {-399.88/6 0.1} 76. fxe8+ {+99.95/16 1.7} Kf9
{-7.52/1 0.1} 77. d9 {+99.97/16 1.7} Eg9 {-399.96/2 0.1} 78. de9#
{+99.99/16 1.3}
{Xboard: Forfeit due to invalid move: g9e7 (g9e7 via `/) res=24} 1-0

[Event "Computer Chess Game"]
[Site ""]
[Date "2016.06.19"]
[Round "93"]
[White "TJxiangqi 0.02"]
[Black "Makulit v1.8"]
[Result "0-1"]
[TimeControl "120+1"]
[Variant "xiangqi"]
[Annotator "13. +0.10   13... -0.16"]

1. Che2 Hg7 2. Hg2 Rh9 3. Rh0 g5 4. Rh6 Hc7 5. Hc2 c5 6. Ra1 Cb6 7. Rh4
Ece7 8. g4 gxg4 9. Rxg4 Hf5 10. Rf1 Cb5 11. Rh1 Ra8 12. c4 cxc4 13. Rxc4
{+0.10/9 3} Rah8 {-0.16/12 7} 14. Rxh7 {+0.18/8 3} Rxh7 {-0.24/14 1.7} 15.
Rxc7 {+0.49/10 2.8} Afe8 {-0.21/15 6} 16. Rc6 {+0.55/10 5} Rg7 {+0.05/13 3}
17. Cxe6 {+1.33/10 8} Rg6 {-0.26/14 4} 18. Rxa6 {+1.43/9 4} Rg3
{-0.13/14 3} 19. Cb6 {+1.37/8 2.6} Cc5 {-0.32/12 4} 20. Ea2 {+1.46/8 1.3}
Hh4 {-0.58/14 4} 21. C6b3 {+1.49/10 3} Rg5 {-0.22/14 4} 22. Hge1
{+1.52/9 3} Ec9 {-0.27/12 4} 23. a4 {+1.47/8 3} Ege7 {-0.14/14 4} 24. a5
{+2.17/9 4} Rf9 {+0.56/14 3} 25. Hd4 {+2.09/9 4} Rf1 {+0.96/15 2.6} 26. Cb1
{+2.19/8 1.7} Cc0+ {+0.98/13 3} 27. Hxc0 {+2.29/4 0.1} Rxb1 {+1.07/14 2.5}
28. Rh6 {+0.30/9 3} Hg2 {+1.05/13 3} 29. Rh9+ {+0.39/8 2.2} Af9
{+1.33/13 2.2} 30. Cb5 {+0.15/9 4} Hxf0 {+1.64/14 2.3} 31. Ae1 {-0.51/9 3}
Hg2 {+1.73/14 3} 32. Ee2 {-0.61/9 5} Rd5 {+1.86/15 3} 33. Hf3 {-1.60/9 2.5}
Rb3 {+1.98/15 3} 34. Hh2 {-2.40/10 10} Rbd3 {+2.31/13 3} 35. Eg0
{-2.50/9 6} R3d4 {+2.08/13 3} 36. Rh3 {-1.80/9 4} Ra4 {+2.73/13 2.9} 37.
Ee2 {-3.41/10 5} Rxa2 {+4.32/16 2.4} 38. Cb2 {-4.09/10 5} Hxe1
{+4.60/18 2.5} 39. Kxe1 {-4.94/12 5} Rc5 {+4.50/17 1.9} 40. Ke0
{-5.46/12 6} Rc2 {+5.07/15 1.9} 41. Kf0 {-6.21/12 10} Rxe2 {+5.24/16 2.4}
42. Rf3 {-6.82/11 7} Rc2 {+7.09/16 2.0} 43. Rxf9+ {-6.17/11 2.8} Ke8
{+3.44/5 0.1} 44. Rf8+ {-7.75/12 5} Ke9 {+3.44/4 0.1} 45. He1 {-16.85/13 7}
Ra0+ {+99.75/16 2.0} 46. Kf1 {-16.82/13 2.1} Rxh2 {+99.81/17 1.9} 47. Rf9+
{-21.32/12 4} Ke8 {+5.32/5 0.1} 48. Hc0 {-190.00/13 5} Rxc0 {+99.87/20 2.6}
49. Rf8+ {-190.00/12 1.2} Ke9 {+13.47/5 0.1} 50. Rf9+ {-190.00/13 2.3} Ke8
{+13.40/4 0.1} 51. Rf8+ {-190.00/13 1.1} Ke9 {+13.45/4 0.1} 52. Rf9+
{-190.00/14 2.7} Ke8 {+9.22/4 0.1}
{Perpetual check by White} 0-1

[hgm]

Well, HaQiKi D does not claim game results, and apparently Makulit doesn't either, and WinBoard does not detect the mate. So the game continues in a checkmate position, and HaQiKi D just plays a random move in such cases, which of course can only be illegal.

Note that WinBoard 4.8 and 4.9 have a Xiangqi bug, which allows the King to leave the Palace. Which means that mate detection often fails, even when it is on. I discovered that only after the 4.9.0 release. WinBoard 4.8.0 has a similar bug for the Advisers, but that is fixed in 4.9.0. This cannot explain why WinBoard did not adjudicate checkmate in the first game, as the way out of the Palace would be blocked by the Elephant. So perhaps mate detection was switched off?

There are actually many Xiangi engines that prefer to lose by delivering (illegal) perpetual check, rather than being checkmated. (Elephant Eye does it too.) I don't know why they are programmed that way. It is just a matter of the score they assign to a repeat brought about by perpetual checking, it seems to be less negative than the score for checkmated (in 0). It could also be that they have slightly different rules for how long you can continue it. Although I don't think so, becauseI have seen it also happen with engines that normally would not repeat even a single time by checking, to postpone a problem. The number of repeats after which WinBoard adjudicates can be set in the Adjudications dialog. I thought that for Xiangqi it had to be the same as for Chess (i.e. 3), and that only Shogi needed 4. But perhaps TJxiangqi counts on 4.

[hgm]

BTW, as you are working on your Xiangqi engine:

Would it be interesting for you if we had a system for Xiangqi End-Game Tables, which could be used by all engines? I have been experimenting a little with XQ EGTs lately, and even end-games with minimal material are horribly complicated to win, and even Elephant Eye bungles them (e.g. KCPEKAAE). A complication unique to Xiangqi is that the winning side can have this redundant defensive material, and that you would want to use an EGT for, say KRKAAEE also for KRAAEEKRAAEE, when the AAEE of the attacker has been moved out of the way. So I only build a partial EGT for KRKAAEE, with the Rook on the enemy half, and made the probing code such that it also uses this when the strong side has extra defenders that are not interfering with the King's outlook (i.e. no Elephant in the Palace, and all Advisers behind the King).

I have not looked into compression yet, because the EGT I built so far are small enough to fit entirely in memory without any compression. These are KRKd (445KB), KH(P)Kd, KHHKd, KP(P)Kd (all four 21MB), and KCPEKd (31MB), where d = any combination of defenders. This can be reduced by at least a factor 2 because of left-right symmetry,and another factor 2 when there are two equal pieces. Of course this will be a different matter when there are three attacking pieces (2 vs 1).

[Evert]

BTW, as you are working on your Xiangqi engine:

Would it be interesting for you if we had a system for Xiangqi End-Game Tables, which could be used by all engines? I have been experimenting a little with XQ EGTs lately, and even end-games with minimal material are horribly complicated to win, and even Elephant Eye bungles them (e.g. KCPEKAAE). A complication unique to Xiangqi is that the winning side can have this redundant defensive material, and that you would want to use an EGT for, say KRKAAEE also for KRAAEEKRAAEE, when the AAEE of the attacker has been moved out of the way. So I only build a partial EGT for KRKAAEE, with the Rook on the enemy half, and made the probing code such that it also uses this when the strong side has extra defenders that are not interfering with the King's outlook (i.e. no Elephant in the Palace, and all Advisers behind the King).

I have not looked into compression yet, because the EGT I built so far are small enough to fit entirely in memory without any compression. These are KRKd (445KB), KH(P)Kd, KHHKd, KP(P)Kd (all four 21MB), and KCPEKd (31MB), where d = any combination of defenders. This can be reduced by at least a factor 2 because of left-right symmetry,and another factor 2 when there are two equal pieces. Of course this will be a different matter when there are three attacking pieces (2 vs 1).

I would be interested in this too.

For compression, given that the files are not terribly large, I'd just pass them through zlib and call it a day...

[mar]

For compression, given that the files are not terribly large, I'd just pass them through zlib and call it a day...

I'd suggest to use zstandard instead: https://github.com/Cyan4973/zstd
decompresses much faster and compresses much better

[Dann Corbit]

For compression, take a look at lz4hc from this project:
https://github.com/Cyan4973/lz4

Its compression speed is not great, but the decompression rate is blazingly fast.

Since you only compress them once (when you make them) the slow decompression does not matter and the super fast decompression is a big bonus.

[Evert]

For compression, given that the files are not terribly large, I'd just pass them through zlib and call it a day...

I'd suggest to use zstandard instead: https://github.com/Cyan4973/zstd
decompresses much faster and compresses much better

Impressive.
I'm really fond of the gzopen family of functions, which let me read from file and file.gz with the same code, which gives me the freedom to decide whether I want to compress things or not. Performance-wise it's not optimal, and perhaps the flexibility of such a choice isn't needed or desired for this.

How generally available is it in package managers? An advantage of zlib is that it is wide-spread.

[Dann Corbit]

Compression ratio is slightly better than LZ4HC ( compression ratio of 2.877 for zstd 0.7.0 verses 2.720 for LZ4HC) but decompresses about 1/2 as fast (930 MB/s for zstd verses 1830 MB/s for lz4hc).

If saving the last byte of space is more important than reading speed then zstd will be better. So perhaps a scheme like Miguel's of user chosen compression method is best of all.

[mar]

Compression ratio is slightly better than LZ4HC ( compression ratio of 2.877 for zstd 0.7.0 verses 2.720 for LZ4HC) but decompresses about 1/2 as fast (930 MB/s for zstd verses 1830 MB/s for lz4hc).

If saving the last byte of space is more important than reading speed then zstd will be better. So perhaps a scheme like Miguel's of user chosen compression method is best of all.

Note that zstd and LZ4 are from the same author, Yann Collet.

While LZ4 decompresses insanely fast, what you want is to minimize IO + decompression time and my bet is that zstd would perform better,
I've no idea how fast SSDs are though.

Even in LZBench, I've seen a (relatively strong) correlation between compressed size and decompression speed (the smaller the better).

The ratio is slightly better (5% is actually nice in compression), note that the figures above are with fastest level while LZ4HC is slowest:

On silesia, zstd level 9 (has 22 levels) compresses ~29% better than LZ4HC; this is huge when we talk compression and huge IO savings.
While zstd doesn't compress as well as LZMA, LZMA decompression very slow (relatively to zlib).

What impressed me most is that zstd decompresses even faster than my simple LZ compression which doesn't even use entropy coding (lame I know - but I'm beating both LZO and LZF in both decompression speed and compression ratio)

[mar]

How generally available is it in package managers? An advantage of zlib is that it is wide-spread.

It's still relatively new (final 1.0 should be coming soon), so I guess it will take some time.
But it's already very stable and very well tested (fuzzy testing).
I also hope he'll decide to go with a slightly more liberal license (zlib or so).

Another interesting feature is the ability to use static dictionary (automatically trained) => this might help tremendously for small independent blocks (it takes time until LZ gets hot when it needs to restart from scratch),
so perhaps this feature may be even more interesting for tablebases,
but I've never tested this so I've no idea if it would be suitable.