"aborting engine think"

[janggi-korea]

The draw result works fine.

gib files too, the score win result depends on the first encoding. So it is relatively accurate for winboard.

In the results, check mate, time win, score win, etc., are partially edited for the convenience of Koreans, so there is no significant impact on the game result.(gib)
Therefore, PGN is the standard, and it is satisfactory if it is marked 1-0, 0-1, 1/2-1/2 according to the PGN rule. As you mentioned, PGN development is essential to mark victory over all rules. However, as of now, janggi also has only 3 types of final results, 1-0, 01-1, 1/2-1/2, so we can entirely include pgn in the results.

The problem is also that there is no result, or when there is a special result the winboard cannot recognize the starting position.
However, this problem for solve requires Koreans to review and edit the file at least once in order to create a gib file for Winboard.

I think this problem cannot be helped. As mentioned earlier, the results are all different. This is not a Winboard problem, but a standard problem for Korean janggi files.


PS. In the actual janggi competition, whether bikjang will judge the result by score or draw when it occurs depends on the competition rules.
But in general, it's mostly a draw rule. The janggi variant is relatively accurate in the rules of the stockfish engine.

If allow repetitive bikjang and pattern repetition, the janggi game will never end.

Most of the time, bikjang is only used in official competitions, and the simpler games of ordinary amateurs ignore the bikjang rules.

I want to create EGTB as well as janggi using the stockfish engine. But I haven't found a way yet. Do you know how to make it?

If janggi also writes egtb, it would be necessary to write EG considering draw for bikjang, EG excluding bikjang, and EG considering score win/loss at bikjang. However, since score wins or loses are rarely used in bikjang, the first two cases seem to be essential.

[H.G.Muller]

The draw result works fine.

gib files too, the score win result depends on the first encoding. So it is relatively accurate for winboard.

In the results, check mate, time win, score win, etc., are partially edited for the convenience of Koreans, so there is no significant impact on the game result.(gib)
Therefore, PGN is the standard, and it is satisfactory if it is marked 1-0, 0-1, 1/2-1/2 according to the PGN rule. As you mentioned, PGN development is essential to mark victory over all rules. However, as of now, janggi also has only 3 types of final results, 1-0, 01-1, 1/2-1/2, so we can entirely include pgn in the results.

The problem is also that there is no result, or when there is a special result the winboard cannot recognize the starting position.
However, this problem for solve requires Koreans to review and edit the file at least once in order to create a gib file for Winboard.

I think this problem cannot be helped. As mentioned earlier, the results are all different. This is not a Winboard problem, but a standard problem for Korean janggi files.

I must admit that I do not understand much of what you are saying here. But if you think the current situation w.r.t. game results is satisfactory, I am happy too.

I want to create EGTB as well as janggi using the stockfish engine. But I haven't found a way yet. Do you know how to make it?

Engines cannot create EGT. This is done by EGT generators, which are completely different programs. Instead of searching forward from the current position, like engines do, they start at the checkmates, and calculate backwards ('retrograde analysis').

If janggi also writes egtb, it would be necessary to write EG considering draw for bikjang, EG excluding bikjang, and EG considering score win/loss at bikjang. However, since score wins or loses are rarely used in bikjang, the first two cases seem to be essential.

Indeed, every rule variation would need its own set of EGT. But that usually means just a small adaptation in the initialization, while the rest of the calculation stays the same. E.g. in the Checkmating Applet you can tick a checkbox whether you want stalemate to be a draw or a win. If you choose it to be a win, then it starts marking all positions where all moves expose the King to check as lost. If you choose it to be a draw it makes an exception for positions where you could safely pass your turn. From then on everything that it does is the same. But of course the results can be very different. In Chess King + 2 Knights vs King is a draw, unless you can checkmate on the first move. But when stalemate counts as a win, it would be a generally won end-game.

[janggi-korea]

I would like to know in detail how to make janggi EGTB. Do you ever need to develop a program to implement it?

https://github.com/ianfab/Fairy-Stockfish/commit/6f7a56d71948a507836ade8d549e444393e9adf0
UCI-cyclone protocol support
The engine developer supported the UCI-cyclone protocol.
I played janggi in UCCI and UCI mode, but the coordinates did not match.
Is there a way to change the coordinates by modifying the engine?

[H.G.Muller]

There should be no problem with the coordinates, if they implemented UCI-cyclone correctly. WinBoard (or actually UCI2WB, the protocol adapter) might not have been aware that the engine was UCCI, causing a mismatch.


Making EGT is basically very simple. (But repetitive, and therefore tedious.) The EGT is a table of game results of all possible positions. To which position a tabulated result belongs is purely dependent on the location in the table; to keep the EGT compact no information to identify the position is stored at all.

Details can vary depending on how you represent the EGT, and this again depends on what you store as results. E.g. you could store Win/Draw/Loss information only, and that would require 2 bits per position. Which you could pack into words or bytes. And if you do that in a clever way, you could even pack 5 WDL results per byte, as only 3 of the 4 possibilities are needed. (And 3^5 = 243 < 256.) OTOH if you want to store 'Distance to Mate' (DTM) you would need to store a number, and make the storage for it large enough to hold the worst case. The other extreme is that you only tabulate Won/Not-Won information; that takes only 1 bit per position.

Then you need an 'indexing scheme', which is a mapping from positions to unique numbers. You could make that very simple (like for Chess number the squares 0-63, and use index = sqrNrWhitePawn*64*64 + sqrNrWhiteKing*64 + sqrNrBlackKing to map KP/K positions on a unique number. This wastes a little space ('broken positions', where two pieces are on the same square), but it has the advantage that it is easily invertible. You can try to save space by excluding illegal positions (like Kings on adjacent squares), but that makes the index calculation slower, and would not save that much (i.e. not a large factor). In Janggi you would of course definitely want to explot the fact that K and A are confined to the Palace, e.g. by having index = sqrNrWhitePawn1*9*9*90 + sqrNrWhitePawn2*9*9 + sqrNrWhiteKing*9 + sqrNrBlackKing, for KPP/K, using a separate numbering system 0-8 for the Palace squares. (I suppose you could actually number the Pawn squares more cleverly as well, as Pawns cannot get everywhere either.)

Suppose you want to make a DTM EGT, and reserve 1 byte per position. How many positions you have depends on the number of pieces in the end-game you make the EGT for. (And in Janggi, what part of the board is accessible to those.) In principle each piece constellation occurs twice: with white to move or with black to move. The way I usually do this is pack the info for both of those in one byte: the lowest bit indicates whether the position with white on move is known to be won. The other 7 bits contain the number of moves black can maximally make before he is checkmated (the DTM), when black has the move, plus 2. That +2 is becase the DTM can be 0 (in positions where black is already checkmated), and I want to reserve the code 0 for positions for which the DTM is not (yet) known. Initially of course nothing is known, so the entire EGT contains zeros.

Then I start by 'seeding' the EGT with wins: all positions where white can capture the black King. The most efficient way to do this is for every possible position with the black King missing, (which is only a fraction of the positions in the EGT, 1/9 in the case of Janggi) generate all moves of the white pieces. And for the destination of that move, the total position with the black King on that square is a lost one (as that move would capture it). So you 'mark' it by setting the lowest bit of the byte for that position to 1.

Second intialization step is to detect the checkmates. For each position that is marked as 'won' (i.e. where black is in check, we have no others yet), try all black moves to see if there is one through which he can get out of check. This is done by probing the EGT: each move causes an index change (a multiple of the change of the board square number, depending on that index calculation), and you test whether the target position is marked as 'won' too. If all possible moves bring you to 'won' positions, the current position is a checkmate, and you set the upper 7 bits to 2. No issues with stalemate in Janggi. (In Xiangi you would also have to do this test for positions where you are not in check, as stalemate is also lost there, and should be labeled 2 too. In Chess you must recognize the stalemate, but label then such that the will never be considered lost even though you have no moves that would escape the loss, for which I reserved DTM code 1.)

That completes the initialization. We can the start iterating: generate the mated-in-(N+1) positions from the mated-in-N (where the just calculated checkmates are the mated-in-0). For this we run through the EGT, and for each 2 we encounter in the DTM bits, we generate all white 'retrograde' moves (sometimes called 'unmoves'). For non-captues unmoves are usually the same as normal moves; running a movie of a chess game backwards in time shows nothing strange until something gets 'uncaptured'; in the latter case it would look like a move to an empty square, but leave behind an opponent piece on the square it came from! In KPP/K there would be nothing to uncapture, though; all the mates must already have all pieces on the board.

From the mated-in-N positions, you do all white unmoves. The positions you reach that way are then marked as 'won', again by setting the lowest bit. If that bit was already set, nothing changes, and you go on with the next white unmove. If it was not marked yet it is 'newly won'; you then mark it, and actually make the white unmove on the board. From this newly-won position you then try all black unmoves. This reaches positions that now no longer can move safely (i.e. without getting mated in N+1) to the newly-won position, so they are 'potentially lost'. But you tentatively 'label' them as mated-in-(N+1) (which would be code N+3 in the DTM field, in my way of encoding DTM).

Then you still have to 'verify' these 'potentially lost' positions. You run again through the entire EGT, and for each of those you generate all black normal moves (i.e. not retrograde). To see if he still can 'escape' to a position that was not (yet) 'won' (only the mate-in-N or faster positions are marked 'won' at this stage). If he can escape, you set the DTM back to 'undecided' (0). If he hasn't, you leave the code for mated-in-(N+1) there, as it is now a verified mated-in-(N+1) position, from which he can only reach mate-in-N-or-faster positions. While running through the EGT, you count how many positions will keep the mated-in-(N+1) DTM.

You keep doing this for increasing N, until you reach the point where no new (longer) checkmates were added. You have then found all forced wins. Positions that did not receive a DTM are then draws.

When black has pieces that can check (or can BikJang), things get more complex: the algorithm as described would consider perpetual checking legal, and the checks would always remain 'escapes' for black, and the positions from which he can check would thus always remain draws. There exists an algorithm that solves that. But, if you still feel up to it, I can explain that later.

[janggi-korea]

Thanks for the detailed explanation.
Some need to manually enter the movement?
I admire your knowledge.

[H.G.Muller]

Some need to manually enter the movement?

Not sure what you mean by that. What movement, and enter where? An EGT doesn't contain any moves.

When you play against it, as in the Checkmating Applet at the link I gave, you of course have to enter the move that you want to play. The Applet then consults the EGT it generated after you loaded the page for each move it can play, to see which one leads to the fastest win or the slowest loss, and plays that one.

[janggi-korea]

Ok i see. I don't know in detail right now about EGT, but i will practice(Site).

The pass implementation was missing in the gib file, so I sent the file by email to confirm.

And can you make a program that can symmetrically change FEN and movement in a pgn file?
Currently BOOK works fine. However, there is a need to incorporate pgn file symmetry. I think I need a tool that can integrate.

[H.G.Muller]

The pass implementation was missing in the gib file, so I sent the file by email to confirm.

Just to be sure: for the moves in that game I get to see

1. 71Á¹72 2. 49º´48 3. ÇѼö½° 4. 18¸¶37 5. ÇѼö½° 6. ÇѼö½°

Moves 3, 5 and 6 are all turn passes? (I am a bit confused since they seem to start with the same codes that are used for 'black' in many of the PGN tags.)

And can you make a program that can symmetrically change FEN and movement in a pgn file?
Currently BOOK works fine. However, there is a need to incorporate pgn file symmetry. I think I need a tool that can integrate.

It seems easy to do with a text editor.

But I don't understand why you would want to do this. It should be totally unnecessary. What do you want to achieve with this?

[janggi-korea]

Yes, 3,5,6 are pass correct. I added a lot of passes on purpose.

The reason I want to convert pgn's symmetry is simple.

This is why i want to integrate all movements into one in order to take advantage of the book's symmetry function.

The reason for consolidation is to add more probabilities and movements of the book, and to identify various movements.

In fact, I've run a lot of tournaments before the book's implementation, and I have a many symmetric pgn.

The book clearly shows a symmetrical movement, but it doesn't ("move +") of left and right movement. This is because sometimes the odds of a book's left and right movement are different.

[edit]

[H.G.Muller]

Yes, 3,5,6 are pass correct. I added a lot of passes on purpose.

I now uploaded a new WinBoard-AA, which does understand the turn passes in .gib game notations.

The reason I want to convert pgn's symmetry is simple.

This is why i want to integrate all movements into one in order to take advantage of the book's symmetry function.

The reason for consolidation is to add more probabilities and movements of the book, and to identify various movements.

In fact, I've run a lot of tournaments before the book's implementation, and I have a many symmetric pgn.

The book clearly shows a symmetrical movement, but it doesn't ("move +") of left and right movement. This is because sometimes the odds of a book's left and right movement are different.

This should not be possible for a -sym book. If it does happen there must be a bug in the current implementation for handling such books, and then we should fix that, rather than messing with PGN files.

What does "odds of a movement" mean? I do not understand what you mean, and in principle it should not be possible (with a -sym book) that two mirror-image positions show different moves, because as far as the book is concerned they are the same position, which occurs in the book only once. Both book probes would therefore retrieve exactly the same data, with the only difference that the probe for the mirrorred position (the one that is not in the book) would print not the moves as they were in the book, but mirrors those first too.

Can you give an example of a position where this happens? (FEN of the position, the moves listed for that position, and the moves listed for the mirror-image of the position.)

The only case where I can imagine something would look strange is when you probe for a symmetric position. This would never have to be mirrored, so a move of (say) the left Elephant would not automatically also occur for the right Elephant. But this should not matter, as the resulting positions would be equivalent.

[janggi-korea]

Thanks for the update.

Your book works very well and is great. The symmetrical movement is also the same.

I just compared movements with books without sym.

I wanted to integrate pgn because the symmetry is different between the book without sym and the book with sym, and the probability I mean is the unified probability.

It’s late today, so I’ll explain it again next time.