Winboard 4.8.0b and xiangqi engines

[Dann Corbit]

LZ4HC is twice as fast (roughly).

The numbers quoted are real MB/sec decompressed from memory.
There is very little difference in size between the two methods.

The reason that Snappy beats LZ4HC in some tests is that it compresses much faster. But for a tablebase, that cost is irrelevant, except when you are building them.

[Ferdy]

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.

Makulit can claim mate it even claims when it is mated. In that game, the winboard adjudication Detect mates was disabled.

When I setup a tournament using a fen in that ending, HaQiKi does not play an invalid move. Winboard Detect Mates was also disabled.

Code: Select all

[Event "Computer Chess Game"]
[Site ""]
[Date "2016.06.23"]
[Round "1"]
[White "Makulit v1.0"]
[Black "HaQiKi D 1.8a"]
[Result "1-0"]
[TimeControl "120+1"]
[Variant "xiangqi"]
[FEN "3P1ke2/4P4/9/9/9/6E2/9/4EA3/4A4/4K4 w 1 1"]
[SetUp "1"]

{--------------
. . . P . k e . .
. . . . P . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . E . .
. . . . . . . . .
. . . . E A . . .
. . . . A . . . .
. . . . K . . . .
white to play
--------------}
1. de9# {+99.99/17}
{White mates} 1-0

[Event "Computer Chess Game"]
[Site ""]
[Date "2016.06.23"]
[Round "2"]
[White "HaQiKi D 1.8a"]
[Black "Makulit v1.0"]
[Result "1-0"]
[TimeControl "120+1"]
[Variant "xiangqi"]
[FEN "3P1ke2/4P4/9/9/9/6E2/9/4EA3/4A4/4K4 w 1 1"]
[SetUp "1"]

{--------------
. . . P . k e . .
. . . . P . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . E . .
. . . . . . . . .
. . . . E A . . .
. . . . A . . . .
. . . . K . . . .
white to play
--------------}
1. de9# {+399.96/1}
{White mates} 1-0

[mar]

LZ4HC = LZ4 with better parsing, decoder is the same.

Again, 30% on Silesia is huge, not very little, but you have to compare apples to apples.
For offline compression you choose a better compression method than fastest (like you said).

Snappy compresses and decompresses fast, but that's it. The ratio is poor. LZ4 compresses much better than Snappy.

[Ferdy]

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?

Sure.

There is a site that I saw on ending tables.
http://lpforth.forthfreak.net/endgame-en.html

Sample rook table, interactive board can be displayed by clicking the link on longest win.
http://lpforth.forthfreak.net/available-rook-js.html

[hgm]

This is indeed a nice site that I had not found yet. They have the strange habit of calling Advisers 'Bishops'; I have never seen that before. Often the Elephants are called Bishops, and abbreviated as B in FEN.

As to compression: I never looked into how this is typically done for EGT. I suppose what is needed is the ability to decompress small chunks of the table as they are needed. Memory is supposed to be a scarcer resource than disk space, so decompressing the entire table for storing it in memory is pointless: if you can afford to have it decompressed in memory, you could afford to store it uncompressed on disk.

Perhaps a good scheme would be to divide up the EGT in P-slices, which have the Pawn(s) in a fixed position, as Pawns are slow-moving pieces. A crossed Pawn can be on 45 different squares, so even if there is only a single Pawn a P-slice measures only 1/45th of the EGT. Not all end-games have Pawns, however.

An alternative would be to slice up the tables by constellation of the weak side's Palace (King + Advisers). There are 119 constellations of K, KA and KAA (9 + 40 + 70). And it can take many moves to traverse through all of them. In that respect the Palace is a slow-moving pseudo-piece. I currently build tables with all possible combinations of defenders, as the usual path to victory is eroding the defense by eating the defenders one by one (possibly at the expense of attacking Pawns) until it is weak enough to force mate. There are 29 possible constellations of 0, 1 or 2 Elephants (1+7+21). So in total there are 29x119 = 3451 constellations of King + defending pieces. A small fraction of these is broken because a King collides with an Elephant. (7 Elephant constellations have an Elephant in the Palace, and 16 Palace constellations have the King on that square, so 112 of the 3451 are broken, and could be removed. Elephants and Advisers cannot collide.) So the EGT could be sub-divided into 3451 fragments by weak-side defender, which are independently compressed, and equiped with an index table to indicate where in the file they start. That still wastes negligible space on the index table.

A typical search that probes into the EGT inside the tree would contain two typesof refutation trees, however. In one of these the losing side plays the all-nodes,toprove he is mated faster than in the PV. And when he plays the all-nodes, he probably will sample all possible defender constellations, while the winning side limits himself to purposeful moves that force a mate. This would then need the entire EGT. It would be much better if the EGT was subdivided based on constellations of pieces from both sides, so that no matter who plays the cut-nodes, the highly selective moving there would limit the access to only a part of the table. So perhaps the independently compressed fragments should be made smaller (and thus larger in number), by alsofixing the location of one of the strong side's attacker pieces (preferably a Pawn). That would cause 45 x (3451 - 112) = 150,255 fragments. To have an index table for those would take a non-negligible space, especially if the start address needed 4 bytes to encode. An alternative would be to just use the 119 Palace states plus the 45 attacker-piece locations to define a fragment (5,355 fragments).

[hgm]

When I setup a tournament using a fen in that ending, HaQiKi does not play an invalid move. Winboard Detect Mates was also disabled.

It seems that mate detection off only affects adjudication in games. When you load a PGN game WinBoard would still append the message {White mates} if the PGN result was missing. The message you see above is WinBoard's. When I let HaQiKi D perform the mating move in that initial position, it just prints the move with a +400 score, but no claim.

[Ferdy]

When I setup a tournament using a fen in that ending, HaQiKi does not play an invalid move. Winboard Detect Mates was also disabled.

It seems that mate detection off only affects adjudication in games. When you load a PGN game WinBoard would still append the message {White mates} if the PGN result was missing. The message you see above is WinBoard's. When I let HaQiKi D perform the mating move in that initial position, it just prints the move with a +400 score, but no claim.

In the two games from fen that I posted, Makulit claimed the win as 1-0 {White mates} and claimed the loss as 1-0 {White mates}. This is probably why {White mates} is in the pgn output.

Yes I can see from the log that HaQiKi D does not claim a mate.