WinBoard, exotic version

[Rein Halbersma]

for the first time my perft numbers for depth 9 match after fixing the bug you reported. I still didnt remove the duplicates (and probably never will) but it matches the number with duplicates.

perft 9
f4g5. 4158878
f4e5. 4340780
h4i5. 6360384
h4g5. 3660528
b4c5. 3688184
b4a5. 5649982
d4e5. 4156481
d4c5. 3631435
j4i5. 5375962
nodes 41022614
time 12.61 sec

Great! If you let it run a few minutes, you probably can match perft 11 as well, just to make sure!

[Daniel Shawul]

It is Nebiyu which crashes because of getting a [-] for grand-chess for example. For other games the castling and ep status crash them. I just wanted to make sure what kind of FEN winboard sends to the engine for games missing some status in FEN. I now understand that I have to make my FEN acceptance somewhat liberal or handle the FEN differently for each game.

[hgm]

Making it liberal is a good and easy option. There is no ambiguity, all fields are recognizable. A holdings field will always follow the board, and will be enclosed in [], characters otherwise not used. An e.p. field will have a digit as second character, which will set it apart from a castling field. (Both start with a lower-case letter) the first thing that start with a digit is the reversible move counter. So just parse it, and ignore what you don't need, and use defaults for what is not present.

Beware for the + that can occur in Shogi FENs (e.g. +B is a promoted white Bishop, i.e. a Dragon Horse). Similarly, in Crazyhouse FENs you can get B~ for a Bishop that is really a promoted Pawn. (Such things can appear only in the board part, as in the holdings they always revert to their base type.)

[Daniel Shawul]

It is working ! But man, my perft speed is embarrassing though almost 8x slower.

perft 10
j4i5. 33549401
h4i5. 40795670
h4g5. 23013462
f4g5. 26332177
f4e5. 27850178
d4e5. 26576196
d4c5. 22570654
b4c5. 23084688
b4a5. 35163256
nodes 258935682
time 79.77 sec
perft 11
b4c5. 150557735
b4a5. 221597326
h4i5. 261843664
h4g5. 146153142
d4e5. 173436656
d4c5. 146316423
f4g5. 169869530
f4e5. 182119415
j4i5. 214313242
nodes 1666207133
time 509.42 sec

[Daniel Shawul]

Making it liberal is a good and easy option. There is no ambiguity, all fields are recognizable. A holdings field will always follow the board, and will be enclosed in [], characters otherwise not used. An e.p. field will have a digit as second character, which will set it apart from a castling field. (Both start with a lower-case letter) the first thing that start with a digit is the reversible move counter. So just parse it, and ignore what you don't need, and use defaults for what is not present.

Thanks I will do so.

Beware for the + that can occur in Shogi FENs (e.g. +B is a promoted white Bishop, i.e. a Dragon Horse). Similarly, in Crazyhouse FENs you can get B~ for a Bishop that is really a promoted Pawn. (Such things can appear only in the board part, as in the holdings they always revert to their base type.)

I represent promoted shogi pieces with different letters. I do not have those + or ~ in my FEN. Where can I get description of FENs for crazyhouse and shogi ? Maybe shokidoki will help me with that.

I am trying to register the first three games only to winboard and see if I can manage to work things out like fairy max does. But first I have to finish off the proble with FEN.

[hgm]

Well, what I told you is basically all there is to it. Promoted pieces in Shogi are indicated by a + prefix to the base piece in the board part, and promoted Pawns in Crazyhouse/Bughouse games with a ~ suffix on the promoted type. This is only important when pieces revert to something else on capture, and is not done in games without holdings, or where they do not revert. The systems for Shogi and Bughouse need to be different, because in one case different pieces promote to the same piece (a Gold), while in the other the same piece (a Pawn) promotes to different pieces.

In games with holdings (this can also be holdings for other purposes than dropping, such as to display captured pieces for selection on promotion, as in Grand Chess), the board is followed by a list of pieces in them between [] brackets (or [-] when the holdings are empty). The order of the pieces between [] is unspecified, and immaterial.

The stm field always contains a single lower-case w or b.

Castling fields can contain KQkq, or file identifiers in FRC/CRC (e.g.HAha).

e.p. fields can contain a single square like e6 or (in Berolina) a double square e6d5 (although WB does not do that yet).

Fields that would always be empty ('-') in a given variant will be left out (so no e.p and castling in Shogi or Xiangqi, no holdings in normal Chess).

Always present and last are the reversible-move counter and the move number, as pure numeric fields.

That is really all. There is currently no method defined for indicating the number of checks in 3checks.

[Rein Halbersma]

It is working ! But man, my perft speed is embarrassing though almost 8x slower.

perft 10
j4i5. 33549401
h4i5. 40795670
h4g5. 23013462
f4g5. 26332177
f4e5. 27850178
d4e5. 26576196
d4c5. 22570654
b4c5. 23084688
b4a5. 35163256
nodes 258935682
time 79.77 sec
perft 11
b4c5. 150557735
b4a5. 221597326
h4i5. 261843664
h4g5. 146153142
d4e5. 173436656
d4c5. 146316423
f4g5. 169869530
f4e5. 182119415
j4i5. 214313242
nodes 1666207133
time 509.42 sec

Nice to see the perft numbers match. My timings used hashing + bulk counting, and perft 11 takes about 12 seconds. Without those optimizations, I get similar timings (within a factor of 2) to yours on my old P4 in 32-bit mode.

[Daniel Shawul]

In games with holdings (this can also be holdings for other purposes than dropping, such as to display captured pieces for selection on promotion, as in Grand Chess), the board is followed by a list of pieces in them between [] brackets (or [-] when the holdings are empty). The order of the pieces between [] is unspecified, and immaterial.

The stm field always contains a single lower-case w or b.

Castling fields can contain KQkq, or file identifiers in FRC/CRC (e.g.HAha).

e.p. fields can contain a single square like e6 or (in Berolina) a double square e6d5 (although WB does not do that yet).

Fields that would always be empty ('-') in a given variant will be left out (so no e.p and castling in Shogi or Xiangqi, no holdings in normal Chess).

Always present and last are the reversible-move counter and the move number, as pure numeric fields.

That is really all. There is currently no method defined for indicating the number of checks in 3checks.

Thanks. I followed exactly this recommendation and got all of my chess games (about 10 of them) working properly. It also undiscovered some bugs I had but now NebiyuChess can match Nebiyu Alien. Which means against fairy-max and other engines as well.

It seems that sending all of the games with board size and holdings like "variant 8x8+0_normal" is ok. Since I check for both "normal" and "8x8+0_normal" in my parser it works for me. Winboard activates the variants button so now there is no need to fix the combo box. Maybe I will drop the combo box now.

For example Shogi is activated when NebiyuAlien is loaded but if I try to play a game against nebiyuchess it warns me that second engine is not capable of playing that variant. So this is good.

I still have to fix the shogi fen. Later.

[Daniel Shawul]

Nice to see the perft numbers match. My timings used hashing + bulk counting, and perft 11 takes about 12 seconds. Without those optimizations, I get similar timings (within a factor of 2) to yours on my old P4 in 32-bit mode.

Thanks that is good to hear. I think 2x is quite reasonable. Piece list capture move generation is very slow , and if checkers is like chess the qsearch tree is much bigger than.

[hgm]

OK, I checked the WinBoard code, and it uses strstr(VARIANTFEATURE, VARIANTNAME) to determine if the engine playes the variant, (and the variant button thus should be enabled in the menu dialog), where VARIANTFEATURE is the string that was sent in feature variants="...". This means that if the VARIANTNAME is "shogi", it would match "9x9+7_shogi", but also "5x5+5_shogi" or "supershogi",if any occurred in the variants feature. This seems wrong; there could be engines that only support 5x5+5_shogi, (min-Shogi) or only 10x10+0_checkers (International Draughts), and WB would not object to them being used for regular Shogi or Checkers, while in fact this would make them crash.

So it seems that the way it currently works should really be considered a WB bug. For the enabling of the menu buttons it is good enough, but if a user would actually try to select regular Shogi with a mini-Shogi engine, the proper response would be "Sorry, this engine does not play regular Shogi". It should only accept the Shogi choice when at the same time the user had overruled the board size to 5x5+5. In other words, after the strstr match check if there are commas directly before and after the matched part. That would break engines that only sent "8x8+0_checkers" and not "checkers" when someone asked for "checkers"...