Fairy-Stockfish janggi (ponder Problem)

[janggi-korea]

After applying the code,
"ponderhit" is well displayed next to the engine name in the engine output window. thank you.

[H.G.Muller]

When you say "in the xiangqi variant", do you mean that you were using the old engine that doesn't know janggi is a standard variant? And in the other case a newer version of the engine?

It seems the engine is not able to properly indicate what should be highlighted when it is pondering. Now that Janggi is a standard variant, it should not be necessary to indicate that anyway: WinBoard knows the rules now by itself.

You can try to replace the highlight=1 in the xboard.cpp file by highlight=0, to suppress the engine highlighting under any conditions, and just leave it to WinBoard to use its own (now built-in) rules for this.

[janggi-korea]

oh I'm sorry to confuse you.
I was test the latest commit, and now I'm going to test against the janggi standard variant commit.
Because a lot of committed recently. So I did tested compatibility.

[H.G.Muller]

OK, I really want to converge on a single working combination of WinBoard and Stockfish, and then continue with that for the book. The Stockfish version should have the ponder modifications, and possibly the pass -> @@@@ substitution, if the official version does not already implement that. And for now also highlight=0 (instead of highlight=1) to exclude any interference of the engine with highlighting. Because there seems to be something wrong with that in combination with pondering.

I think I know what the problem is: during pondering the engine is not thinking about the same position as there is in the game; it has speculatively performed the expected move, and is already thinking on its own move after that. So according to the engine the other side is on move, and the engine will not find any moves for any piece you can click in the list of currenly legal moves (which are all opponent moves). So it will attempt to make every move illegal through the highlighting.

I guess eventually I should fix this, by making a copy of the game state before the engine starts to ponder, and use that copy for generating the highlights. But until then we should switch the highlighting by the engine off. It should not be needed anymore now WinBoard knows the Janggi rules by itself.

[janggi-korea]

I tested against the janggi standard variant. And i did merged with your ponder file, and the latest janggi commit.
I changed it to "highlight = 0", and I checked the return "@@@@". The turn "pass" worked fine, and in Winboard's janggi standard variant the engine worked relatively well.

But I'm not sure about the engine "ponder" but that's normal speculation. At least it seems to me that it works fine. But once again I need your confirmation.

1. so, I have shared with you the engine files I compiled and all the source code merged on Google Drive.
1024.exe / Fairy-Stockfish-master.zip

2. variant=janggimodern, variant=janggicasual, variant=janggitraditional
These 3 variants seem to be unplayable in the Winboard standard janggi variant.
It seems to be playing back in the xaingqi variant. Because the pieces char changed. And "highlight dragging" doesn't work. Can you help me to play with the standard janggi variant normally by adding the above 3 variant names to the code?
Or what should I change in the engine source code?
*Command I used: variant=janggimodern -fcp "Z:\1024.exe"


Variant* janggi_variant() {
Variant* v = xiangqi_variant();
v->variantTemplate = "janggi";
.
.
.// Traditional rules of Janggi, where bikjang is a draw
Variant* janggi_traditional_variant() {
Variant* v = janggi_variant();
v->bikjangRule = true;
v->materialCounting = NO_MATERIAL_COUNTING;
return v;
}
// Modern rules of Janggi, where bikjang is not considered, but material counting is.
// The repetition rules are also adjusted for better compatibility with Kakao Janggi.
Variant* janggi_modern_variant() {
Variant* v = janggi_variant();
v->bikjangRule = false;
v->materialCounting = JANGGI_MATERIAL;
v->moveRepetitionIllegal = true;
v->nFoldRule = 4; // avoid nFold being triggered before move repetition
return v;
}
// Casual rules of Janggi, where bikjang and material counting are not considered
Variant* janggi_casual_variant() {
Variant* v = janggi_variant();
v->bikjangRule = false;
v->materialCounting = NO_MATERIAL_COUNTING;
return v;

[H.G.Muller]

I tried the 1024.exe. It still says highlight=1, and with legality testing off this produces faulty highlights (namely completely absent) when pondering. Which then prevents playing any move. Fortunately WinBoard has a work-around for this, which can overrule what the engine says. When I add the extra WinBoard option

-firstFeatures "highlight=0"

everything behaves as if Stockfish had said that. So there isn't really any need to modify the highlight=1 setting in Stockfish itself.

Pondering seems to work in variant janggi. Stockfish does not always seem to produce a move to ponder on, though, and in that case the engine is idle when the user thinks.

Several problems manifested themselves with the other 3 variants, though. Because these are engine-defined variants, WinBoard will always obey the engine, even when legality testing is on. It cannot know that the rules are practically the same as for the parent variant janggi, and only differ in result calculation.

The problem now is that Stockfish tries to affect the rules in several ways:
1 - It changes the piece images, Pawns to Marshalls, which affects the opening book.
2 - It specifies new moves for all the pieces at the start of the game.
3 - It tries to apply highlights on a per-move basis, when you 'pick up' a piece, to show where it can move to.

There is no way to suppress (1) in an engine-defined variant. (In standard variants you can suppress it by switching legality testing on.) So this has to be changed in Stockfish. I have yet to find out where.
The move specification (2) is inaccurate, because the general mechanism for this is not so detailed that it can handle the very special Janggi rules (confinement to Palace, different board topology in Palace, Cannons not jumping each other). But these inaccurate / faulty moves overrule WinBoard's (now correct) built-in moves. Stockfish should never have redefined pieces that the parent variant knows better than that they can be defined. This used not to be a problem, because the per-move highlighting again overrules the general move redefinition, each time you pick up a piece.
But when the highlighting is suppressed (because it is wrong during pondering), the faulty piece redefinitions prefail again. And there is no way to make the GUI ignore those in an engine-defined variant.

So it becomes essential to suppress Stockfish' sending of 'piece' commands to redefine the moves in Stockfish the Janggi variants. With highlighting disabled they wreck things by replacing the correct moves by wrong ones, and with highlighting enabled they serve no purpose (and would wreck checkmate detection, which is not helped by highlighting). So they are always counter-productive, even when I would repair the highlighting, now that WinBoard knows the moves by itself.

[janggi-korea]

Thanks, I'll add -firstFeatures "highlight = 0" to the engine command.

https://github.com/ianfab/Fairy-Stockfish/commit/9147800a1e979c0ebc8455e1ef08d20dd2f8c7da
This is the commit that the engine developer defined the standard janggi for, but unfortunately i can't run the other 3 variants on winboard.
The defined file is ucioption.cpp / variant.cpp.

If can i solve it by changing the pieceToCharTable character in ucioption.cpp? Is it possible to solve it?


The reason engine developers redefine the movement rules (highlight movements) was for janggi and winboard compatibility. Previously, it was run on the xaingqi variant, but because there were many errors in the movement of the palace. Perhaps only the xaingqi movement method was possible. The movement of the palace is different between janggi and xaingqi.
because, it was because Winboard didn't know janggi's rules of movement back then.

ps. I thought that sometimes stockfish stopping ponder had something to do with ponderhit. When I did move what the engine was thinking, the engine moved immediately, and it seemed to stop pondering for a while.

[H.G.Muller]

OK, indeed I figured out now that the code that does this in in ucioptions.cpp.

One improvement should be to add, directly below the line

Code: Select all

        // https://www.gnu.org/software/xboard/Betza.html

the statement

Code: Select all

        if(v->variantTemplate == "janggi") return;

This should suppress all the 'piece' commands that redefine the piece moves whenever the parent variant is Janggi.

The pieceToCharTable can be changed in the file variants.cpp. For Janggi this now says

Code: Select all

        v->pieceToCharTable = ".N.R.AB.P..C.........K.n.r.ab.p..c.........k";

which should be changed to

Code: Select all

        v->pieceToCharTable = "PH.R.AE..K.C.ph.r.ae..k.c.";

That should solve the choice of symbols, and the engine's inclination to force the piece IDs to N and B.

I am still thinking on how to make the highlighting 'ponder proof'. But we don't really need the highlighting in Janggi, where all piece moves are now hard-coded in WinBoard. It is still bad that the version of Stockfish we are making now would be broken for some other variants that do need the highlighting.

One way to do that would be to enclose the code that handles the "lift" command now (in xboard.cpp) between subroutine calls that take back a move when the engine is pondering (undo_move, to get back to the game position) and re-apply the ponderMove immediately afterwards (do_move). I am not sure whether the search threads, which are doing the pondering at that time, are not using the same game-state variable 'pos', so that messing with it would completely wreck the ponder search. Perhaps we should just try:

Just above the line

Code: Select all

          for (const auto& m : MoveList<LEGAL>(pos))

put

Code: Select all

          if(ponderMove != "") undo_move(pos, moveList, states);

and just before

Code: Select all

          // Generate color FEN

put

Code: Select all

          if(ponderMove != "") do_move(pos, moveList, states, UCI::to_move(pos, ponderMove));

If this works you should be able to use highlight=1 again, and highlights should appear even when pondering.

[janggi-korea]

thank you very much~!!
I solved this. The movement display is now active and works fine.

[edit] This problem means that using the 3-janggi variant has been resolved.

[H.G.Muller]

Does that mean all known problems in the engine are solved now, so that we can go back to the opening book issues?

[janggi-korea]

Finally, we have to solve this so the "Ponder" problem ends.

1. Even if I stopped the game during the game, "ponder" was still working. Even with the "New Game / Edit Game / Abort" menu, the contemplation was still "ponder" working on Winboard.

2. middle of the game, even if I started a new game with "New Game" menu, "ponder" was still running. (The cpu was still 100% in use.)

3. Ponder is stopped only when winboard is shut down.

note. However, in the edit game menu, I was able to stop with one movement.

[H.G.Muller]

Ah yes, of course. Ponder searches should not only be terminated when there is a user move, but also on the 'force' command.

Try to put this code in xboard.cpp in the place how "force" is handled now:

Code: Select all

  else if (token == "force")
  {
      if(ponderMove != "") // we were pondering, stop that
      {
          Threads.stop = true;
          Threads.main()->wait_for_search_finished();
          undo_move(pos, moveList, states);
      }
      playColor = COLOR_NB;
  }
  else if (token == "go")


I think that WinBoard would always send 'force' to an engine that is not yet in force mode, before sending any other command. So this should be enough. If there are still other situations where pondering does not stop when it should, please let me know, then we can put similar code in the handling of those.

[janggi-korea]

I modified the code and tested it today.
"Ponder" stopped normally in Edit Game / Abort.
However, if i run "New Game" in the game playing, Winboard always has shut down. so i need re run Winboard.
run "New Game" in the game playing, i think, seems like a user problem. I mean during the game


But it doesn't matter much. Because it can be used enough as an edit game.
good. It works very well.^^

[H.G.Muller]

You mean that WinBoard always exits when you select New Game from the menu when it was in Machine White or Machine Black mode? This is not as it should be. And it does not happen for me, e.g. with the 1024.exe that you gave me. I can start WinBoard with it, switch to Janggi through the New Variant dialog, Start playing against it with white (ponder off), and after a few moves hit New Game. This just displays the start position, and I can enter a new white move, which sets the engine thinking again.

Does this only happen with pondering on? What does WinBoard say, do you get a 'Fatal Error' popup?

[janggi-korea]

Message content:
"Error: chess program exited unexpectedly"

This is when "New game" is executed during "pondering", the winboard is ended and the message is displayed. (Human vs W / H vs B / W vs B)
=================================================
else if (token == "force")
{
if(ponderMove != "") // we were pondering, stop that
{
Threads.stop = true;
Threads.main()->wait_for_search_finished();
undo_move(pos, moveList, states);
}
playColor = COLOR_NB;
}
else if (token == "go")
==================================================
The engine used the engine with the above code applied.
It looks like a problem after applying the above code.

For your confirmation, I uploaded the xboard.cpp file and engine file to Google Drive.

[H.G.Muller]

Well, WinBoard would indeed send a 'force' command to a playing engine before it would send 'new' to start a new game. The error message indicates that the engine crashes. I suppose this only happens with pondering on? Without pondering ponderMove should always be the empty string, and the code should never be executed.

I copy-pasted that code from the place where a usermove is arriving when the engine is pondering, and it is a ponder miss. The ponder search then has to be aborted too. The code seems to work fine there.

It could be there is a timing problem here; Stopping the ponder search leads to sending of a 'feature' command to the GUI. But the 'force' command that is being processed here is probably the first of an entire bunch of commands, which are sent together by WinBoard. So the 'rejected' reply to the 'feature' command (telling the engine the ponder search was stopped, and clearing ponderMove) will only arrive after the commands directly following the 'force' have been processed. During which ponderMove has not been cleared yet. So perhaps some of these commands mistakenly thinks Stockfish is still pondering, and does something it should not have done, which proves fatal.

Can you post a debug log here of a case where this happens, so that I can see which command is responsible for the engin crash?

[janggi-korea]

Since this is a problem that always occurs when starting a new game while pondering,
I think, "pondering" with "new game" command is collide..


>> lift a3
<< highlight 9/9/9/9/9/Y8/1Y7/9/9/9
>> put b3
>> time 30000
>> otim 30000
>> usermove a3b3
<< info string classical evaluation enabled
<< 1 54 0 260 1 130000 0 b9c7
<< 2 73 3 39281 2 1091138 0 b9c7 a0a1
<< 3 25 3 39803 3 1105638 0 g6f6 b0c2 h9g7
<< 4 32 3 40138 4 1114944 0 g6f6 b0c2 h9g7 h0g2
<< 5 25 3 40468 5 1093729 0 g6f6 b0c2 h9g7 h0g2 h7e7
<< 6 25 3 40928 6 1106162 0 g6f6 b0c2 h9g7 h0g2 h7e7 h2e2
<< 7 18 3 41559 7 1123216 0 g6f6 b0c2 b9c7 h0g2 h9g7 h2e2 e8f8
<< 8 4 4 54880 12 1120000 0 g6f6 h0g2 h9g7 h2e2 i6h6 g3f3 b9c7
<< 9 35 6 67570 9 1089838 0 b9c7 h0g2 h9g7 b0c2 i6h6 g3f3 b7e7
<< 10 52 10 109735 11 1055144 0 h9g7 h0g2 b9c7 b0c2 c6d6 h2e2 i6h6 g3f3
<< 11 35 26 250681 14 960463 0 i6h6 b0c2 b9c7 h0g2 h9g7 e1e0 e8e9 f0f1 c6d6 d0e1 d9e8 g3f3 b7e7
<< 12 38 33 321384 15 970948 0 i6h6 h0g2 h9g7 e1e0 b9c7 d0e1 b7d7 b0c2 c6d6 a0a1 e8e9
<< 13 42 46 455557 17 973412 0 i6h6 h0g2 b9c7 e1e0 b7d7 b0c2 h9g7 g3f3 c6d6 d0e1 e8e9 h2f2 d9e8 b2e2
<< 14 38 100 982947 20 976114 0 b9c7 i3h3 h9g7 h0g2 e8e9 e1e0 d9e8 f0e1 h7e7 b0c2 c6d6 c3d3 g6h6 i0h0 b7d7
<< 15 29 144 1410685 22 978962 0 b9c7 i3h3 h9g7 h0g2 e8e9 e1e0 h7e7 b0c2 f9e8 g3f3 e7i7 i0h0 g6h6 f0e1 c6d6 h2f2
<< 16 38 187 1834389 21 977819 0 i6h6 b0c2 e8e9 e1e0 b9c7 h0g2 h9g7 h2f2 h7e7 f0e1 d9e8 a0a4 e6d6 g3f3 b7d7 e0f0 e7i7
<< 17 41 201 1975265 18 979794 0 i6h6 b0c2 e8e9 e1e0 b9c7 h0g2 h9g7 d0e1 f9e8 e3f3 c6d6 a0a4 b7e7 c0e3 e7e5 h2e2 h7d7
<< 18 41 268 2643012 24 984362 0 i6h6 b0c2 e8e9 e1e0 h9g7 e3f3 b9c7 f0e1 f9e8 h0g2 a6a5 h2f2 c6d6 c2e3 a9a6 f2i2
<< 19 35 422 4143001 24 980824 0 i6h6 b0c2 e8e9 e1f1 b9c7 h0g2 h9g7 f0e1 d9e8 h2f2 c6d6 a0a4 a6a5 a4a1 h7h2 i0i2 h2h8 g3f3
<< 20 41 670 6510853 25 971189 0 i6h6 b0c2 b9c7 h0g2 e8e9 e1f1 h9g7 f0e1 d9e8 a0a4 e6d6 e3f3 g6g5 g0e3 h7h5 f3f4 h5c5 a4c4 c9e6 h2f2
<< 21 33 889 8584769 29 964797 0 i6h6 b0c2
<< 21 41 1023 9869624 29 964301 0 i6h6
<< 21 41 1048 10107665 29 964379 0 i6h6 h0g2 b9c7 b0c2 h9g7 h2f2 e8e9 e1f1 d9e8 e3f3 a6a5 d0e1 c6d6 c0e3 b7d7 c3c4 h7e7 b2b4 e9d9 a0e0 @@@@ c4d4
<< 22 33 1135 10939719 24 963851 0 i6h6 h0g2
<< 22 41 1329 12798744 27 962601 0 i6h6
<< 22 37 1417 13607277 28 959745 0 i6h6 b0c2 b9c7 h0g2 h9g7 e1f1 e8e9 h2f2 d9e8 f0e1 i9i5 i0i2 h7f7 a0a4 f7d9 e3f3 b7e7 c0e3 e6d6 b2e2 g9e6 a4g4
<< 23 35 1592 15133043 26 950030 0 i6h6 b0c2 b9c7 h0g2 h9g7 e1f1 e8e9 h2f2 d9e8 f0e1 i9i5 e3f3 a6a5 c3c4 c6d6 b2b4 b7e7 c0e3 i5g5 c4d4 h7h2 i0i2
<< feature GOTMOVE=1
>> rejected GOTMOVE
<< move i6h6
<< Hint: b0c2
<< info string classical evaluation enabled
<< 1 43 0 386 1 386000 0 b9c7
<< 2 43 0 750 2 750000 0 b9c7 h0g2
<< 3 35 0 1156 3 1156000 0 b9c7 h0g2 h9g7
<< 4 35 0 1603 4 801500 0 b9c7 h0g2 b7e7 e1e0
<< 5 38 0 2316 5 1158000 0 e8e9 h0g2 h9g7 e3f3 b9c7
<< 6 39 0 3155 7 1577500 0 b9c7 h0g2 h9g7 e3f3 b7e7 e1f1 e7a7
<< 7 38 0 3973 7 1324333 0 e8e9 h0g2 h9g7 e3f3 b9c7 g0e3 c6d6
<< 8 39 0 5243 8 1747666 0 e8e9 h0g2 h9g7 e3f3 b9c7 g0e3 c6d6 a0a4
<< 9 39 0 7454 11 1863500 0 b9c7 h0g2 h9g7 e3f3 b7e7 e1f1 e7a7 b2e2 h7e7 e2a2 e8e9
<< 10 39 0 9791 12 1958200 0 b9c7 h0g2 h9g7 e3f3 b7e7 e1f1 e7a7 b2e2 h7e7 e2a2 e8e9 g0e3
<< 11 39 0 11771 12 1961833 0 b9c7 h0g2 h9g7 e3f3 b7e7 e1f1 e7a7 b2e2 h7e7 e2a2 e8e9 g0e3
<< 12 39 0 14119 13 1764875 0 b9c7 h0g2 h9g7 e3f3 b7e7 e1f1 e7a7 b2e2 h7e7 e2a2 e8e9 g0e3 c6d6
<< 13 39 0 17214 16 1912666 0 b9c7 h0g2 h9g7 e3f3 b7e7 e1f1 e7a7 b2e2 h7e7 e2a2 e8e9 g0e3 c6d6 f0e1 a6b6 a2e2
<< 14 38 7 111756 20 1432769 0 h9g7 h0g2 b9c7 e1f1 e8e9 h2f2 d9e8 i3i4 h7f7 g3f3 f7d9 f0e1 c6d6 c3c4 b7e7
<< 15 39 16 196149 20 1210796 0 h9g7 h0g2 b9c7 e3f3 b7e7 e1f1 e8e9 a0a4 h7f7 h2f2 c6c5 a4d4 f9e8 c0e3 d9d8
<< 16 39 16 197957 17 1207054 0 h9g7 h0g2 b9c7 e3f3 b7e7 e1f1 e8e9 a0a4 h7f7 h2f2 c6c5 a4d4 f9e8 c0e3 d9d8 f0e1 f7d9
<< 17 39 16 202401 18 1204767 0 h9g7 h0g2 b9c7 e3f3 b7e7 e1f1 e8e9 a0a4 h7f7 h2f2 c6c5 a4d4 f9e8 c0e3 d9d8 f0e1 f7d9 d4i4
<< 18 39 21 243806 19 1139280 0 h9g7 h0g2 b9c7 e3f3 b7e7 e1f1 e8e9 a0a4 h7f7 h2f2 c6c5 a4d4 f9e8 c0e3 d9d8 f0e1 f7d9 d4i4 i9i4
<< 19 41 30 319793 23 1055422 0 h9g7 h0g2 b9c7 e3f3 b7e7 e1f1 e7a7 b2e2 h7e7 e2a2 e8e9 g0e3 c6d6 f0e1 d9e8 a0a1 e7b7 f1f0 i9i7 h2f2 b7b2 a1b1
<< 20 41 104 1040080 29 994340 0 h9g7 h0g2 b9c7 e3f3 b7e7 e1f1 e7a7 b2e2 h7e7 e2a2 e8e9 g0e3 c6d6 h2f2 d9e8 a0a1 a6b6 a2a0 c9a6 a1d1 a9a8 f0e1
>> force
<< 21 41 284 2754196 29 967742 0 h9g7 h0g2 b9c7 e3f3 b7e7 e1f1 e7a7 b2e2 h7e7 e2a2 e8e9 g0e3 c6d6 h2f2 d9e8 a0a1 a6b6 a2a0 c9a6 a1d1 a9a8 f0e1
<< 20 41 284 2754196 25 967742 0 h9g7 h0g2 b9c7 e1f1 e8e9 h2f2 d9e8 a0a4 e6d6 f0e1 i9i5 i0i2 c9e6 i3h3 i5c5 c3c4 c5g5 e3f3 h7h5 b2b4 b7d7 a4a1 e9d9
<< feature GOTMOVE=1
>> ping 2
<< pong 2
>> memory 4100
>> cores 12
>> new

[H.G.Muller]

So it seems that it indeed goes well through the 'force' itself, but that this somehow leaves a situation that interferes with correct operation of the 'new' command. I will have a look to see what exactly the 'new' command does in SF; perhaps this will give me an idea what goes wrong. The 'rejected' command that would be given in reply to the 'feature GOTMOVE' has not been received yet at this point, so ponderMove has not been cleared. This seems the only difference with doing New Game with pondering off, so it must have something to do with that.

[janggi-korea]

OK i see.
Anyway, users no reason to start a new game again from a game already in progress. i consider it a natural processor to start a new game after ending the current game.

[H.G.Muller]

One way to prevent that WinBoard would ever use the engine for playing more that one game is to put the WinBoard option -xreuse on the engine line (with Edit Engine List). WinBoard will then restart a new engine process for every game, and that would prevent this error. This would of course make it completely impossible to remember the hash table from one game to the next, though.

The same can be achieved automatically by letting the engine print feature reuse=0 at startup. E.g change the line (in xboard.cpp)

Code: Select all

                << "highlight=1 name=0 sigint=0 ping=1 myname=\""

to

Code: Select all

                << "highlight=1 reuse=0 name=0 sigint=0 ping=1 myname=\""