SjaakII 1.0 RC1

[hgm]

Ok, the immediate problem with analysis mode was caused by a change in the way moves are parsed, but analysis mode turns out to have been badly broken. I can't tell how it ever could have worked in the first place (at least not if you tried to undo moves and input new ones).

It was using the same board for inputting moves as on which it was analyzing?

I encountered similar problems in HaChu, which is my only engine that uses the highlight protocol: I originally used the search board for generating the color FEN, which worked fine in ponder off games, but made it actually impossible to enter moves when the engine was pondering (or analysing).

Should be fixed locally, but I do have one comment/question regarding the implementation and the CECP specs. Specifically:

new Reset position to start of game but stay in analyze mode.

In normal mode, "new" has the following description if we cut out all cruft that doesn't apply in analysis (force) mode:

new

Reset the board to the standard chess starting position.
[…]
Remove any search depth limit previously set by the sd command.

Apparently, "reset the board to the standard chess starting position." also implies switching back to variant "normal". I'm assuming this is not intended to be the case for "new" in analysis mode, in other words, they're different commands despite being called the same (I understand the historical reasons for this distinction).

Well, it is a bit of a moot point, because XBoard does never use 'new' or 'setboard' on an engine that is in analysis mode. There seems no reason not to reset the engine, because it would have to start a new search from the new position anyway. I don't know what other interfaces do, but usually they would not support any variants, so the switch back to 'normal' would be a noop. In FRC it is not clear what else 'new' could do than setting up FIDE; you would hardly want to start analyzing a randomly chosen position!

I guess the specs should be reformulated to say that 'new' would be equivalent to a setboard of the start position of the current variant, and nothing else.

[Evert]

Ok, the immediate problem with analysis mode was caused by a change in the way moves are parsed, but analysis mode turns out to have been badly broken. I can't tell how it ever could have worked in the first place (at least not if you tried to undo moves and input new ones).

It was using the same board for inputting moves as on which it was analyzing?

Yup.
Which is funny, because I had some code in there to make sure you were allowed to select a move that is legal in the root board position. Never mind that it would subsequently enter the move on the wrong board and completely screw things up.

Should be fixed locally, but I do have one comment/question regarding the implementation and the CECP specs. Specifically:

new Reset position to start of game but stay in analyze mode.

In normal mode, "new" has the following description if we cut out all cruft that doesn't apply in analysis (force) mode:

new

Reset the board to the standard chess starting position.
[…]
Remove any search depth limit previously set by the sd command.

Apparently, "reset the board to the standard chess starting position." also implies switching back to variant "normal". I'm assuming this is not intended to be the case for "new" in analysis mode, in other words, they're different commands despite being called the same (I understand the historical reasons for this distinction).

Well, it is a bit of a moot point, because XBoard does never use 'new' or 'setboard' on an engine that is in analysis mode. There seems no reason not to reset the engine, because it would have to start a new search from the new position anyway. I don't know what other interfaces do, but usually they would not support any variants, so the switch back to 'normal' would be a noop. In FRC it is not clear what else 'new' could do than setting up FIDE; you would hardly want to start analyzing a randomly chosen position!

My suggestion would be to discourage new/setboard in analysis mode and remove the mention thereof from the current description of the protocol. Although I suppose having buggy implementations in engines doesn't hurt if the feature is never actually used...

As for FRC, I suppose "new" could mean "restart from the last starting position".

[hgm]

Well, I have to retract part of that, regarding setboard. And it was I who actually did that: when you play a null move in analyze mode in variants where null move is not legal, XBoard would send the new position to the engine rather than a move. (And instead of an undo from that position it would then send the position after the previous null move, plus all moves that followed it upto the next null move.) So setboard can now be sent by XBoard during analyze mode.

Even whenever more than a single move or undo would be needed, XBoard takes the engine out of analyze mode to enter these, and gives a new analyze command afterwards, This to prevent the engine starts to cough up analyses for every intermediate position. (I did not do this for the second engine, when that is also analyzing; I should probably fix this.) So the whole idea of making the engine receptive to anything but 'exit' in analysis mode was probably a bust. (And 'exit' itself just seems synonymous to 'force'...)

[hgm]

Yup.
Which is funny, because I had some code in there to make sure you were allowed to select a move that is legal in the root board position. Never mind that it would subsequently enter the move on the wrong board and completely screw things up.

Normally I abort the search for any command other than '.', time, otim, usermove, and the latter only allows the search to continue when it is a ponder hit. And in that case the move would already have been done before the search started. All aborting commands would be backlogged, and reparsed after return from the root, so moves would always be done in the root.

The 'lift' command was a border case, though. Normally you would only touch pieces because you plan to enter a move. But a malicious user could incessanly abort the ponder search of an engine opponents by touching his pieces without actually moving them. And it also gave an unquiet engine output display diring analysis, restarting a search several times when entering a move.

So I decided that 'lift' should be processed during search (and 'put' and 'hover' ignored). But that of course raises the problem of the continually modifying board. Rather than keeping a board copy, I derive the highlight from the moves at the bottom of the move stack. And order dummy 1-ply searches when a user command alters the board without triggering a search.

[Ferdy]

Windows 32 and 64 bit binaries are up.

Thanks Martin!

Tried the crazyhouse variant using the winboard tourney manager, everything went smoothly except winboard 4.8.0b crashed after couple of games were finished.
I delete the * under result in trn file, and this resulted in more games played between Imortal and Sunsetter.
TC 5 minutes + 1 sec inc/move.

Code: Select all

Head to head statistics:

1) Sunsetter 7e ZH                507 :     30 (+20,=0,-10),  66.7 %

   vs.                                :  games (  +, =,  -),   (%) :   Diff,  SD, CFS (%)
   TJchessWB_1.1_64bit_ZH             :     10 (  6, 0,  4),  60.0 :    +40,  64,   73.5
   Imortal v1.0                       :     12 (  8, 0,  4),  66.7 :    +59,  64,   82.3
   SjaakII_win64_1.0 RC3b_MS_ZH       :      8 (  6, 0,  2),  75.0 :   +507, 108,  100.0

2) TJchessWB_1.1_64bit_ZH         467 :     30 (+19,=0,-11),  63.3 %

   vs.                                :  games (  +, =,  -),   (%) :   Diff,  SD, CFS (%)
   Sunsetter 7e ZH                    :     10 (  4, 0,  6),  40.0 :    -40,  64,   26.5
   Imortal v1.0                       :     10 (  5, 0,  5),  50.0 :    +19,  61,   62.4
   SjaakII_win64_1.0 RC3b_MS_ZH       :     10 ( 10, 0,  0), 100.0 :   +467, 107,  100.0

3) Imortal v1.0                   447 :     32 (+19,=0,-13),  59.4 %

   vs.                                :  games (  +, =,  -),   (%) :   Diff,  SD, CFS (%)
   Sunsetter 7e ZH                    :     12 (  4, 0,  8),  33.3 :    -59,  64,   17.7
   TJchessWB_1.1_64bit_ZH             :     10 (  5, 0,  5),  50.0 :    -19,  61,   37.6
   SjaakII_win64_1.0 RC3b_MS_ZH       :     10 ( 10, 0,  0), 100.0 :   +447, 108,  100.0

4) SjaakII_win64_1.0 RC3b_MS_ZH     0 :     28 (+2,=0,-26),   7.1 %

   vs.                                :  games ( +, =,  -),   (%) :   Diff,  SD, CFS (%)
   Sunsetter 7e ZH                    :      8 ( 2, 0,  6),  25.0 :   -507, 108,    0.0
   TJchessWB_1.1_64bit_ZH             :     10 ( 0, 0, 10),   0.0 :   -467, 107,    0.0
   Imortal v1.0                       :     10 ( 0, 0, 10),   0.0 :   -447, 108,    0.0

[hgm]

It seems that Sjaak II's highlight command is broken now. Either the color FEN is missing completely, or consists entirely of garbage characters.

As a result it is no longer possible to play with legality testing off.

This is in version RC3b, which I believe is still the latest version.

[Evert]

It seems that Sjaak II's highlight command is broken now. Either the color FEN is missing completely, or consists entirely of garbage characters.

Is this for Omega, or for other variants?
I think the diagnosed problem was for Omega, and I know I verified that it worked there...

This is in version RC3b, which I believe is still the latest version.

Just about. Having fixed (as I thought) the reported issues, I was aiming to bump to version 1.0 proper tonight or tomorrow, but this is a show-stopper. I don't think I've made any changes since RC3b to the code that builds the colour-FENs.

Let me see if I can reproduce it here.

[Evert]

This is in version RC3b, which I believe is still the latest version.

Just about. Having fixed (as I thought) the reported issues, I was aiming to bump to version 1.0 proper tonight or tomorrow, but this is a show-stopper. I don't think I've made any changes since RC3b to the code that builds the colour-FENs.

Let me see if I can reproduce it here.

Ok, turns out I can. It now turns out that it now only works for Omega Chess.
Fix is easy though,

Code: Select all

Index: ../src/xboard.cc
===================================================================
--- ../src/xboard.cc	(revision 272)
+++ ../src/xboard.cc	(working copy)
@@ -780,10 +780,12 @@
    }
 
    int n = 0;
-   for (int r = game->virtual_ranks-1; r>=0; r--) {
+   int ranks = (game->virtual_ranks > 0) ? game->virtual_ranks : game->ranks;
+   int files = (game->virtual_files > 0) ? game->virtual_files : game->files;
+   for (int r = ranks-1; r>=0; r--) {
       int count = 0;
-      for (int f = 0; f < game->virtual_files; f++) {
-         int s = f + r * game->virtual_files;
+      for (int f = 0; f < files; f++) {
+         int s = f + r * files;
 
          /* Empty? */
          if (move_board[s] == 0) {

Martin just made Windows binaries for what I had intended to be 1.0 (but can't be because of this bug), would you be able to quickly check if there are any other issues with them (http://www.crabaware.com/sjaak/sjaakII_win_compiles.zip)? In particular, analysis mode should work correctly and it should do the correct thing when loading/unloading a variant definition file with respect to sending variant options to XBoard/WinBoard. I know it worked when I tried it on my end, but if I'm going to ask for more Windows builds I might as well check if there aren't any other glaring issues with the code I have now.

[hgm]

Well, I don't really know the rules of Sittuyin. But when I select it, and then try to drop a white piece somewhere behind the Pawn line, Sjaak (64 bit) crashes. Which seems always wrong.

[hgm]

Sjaak also doesn't seem to understand an '=' suffix as deferral, in Shogi-like variants.