Seirawan Chess: Sigla, Sjaak, Leonidas

[Evert]

Simply it does not know h1e1 and something similar as castling move. I probably need more time to solve this for the sake of completeness.
Does Leonidas know about this type of move?

I actually didn't remember and had to check, but yes: Leonidas interprets "h1e1e" as a castling move with gating on the rook square (and "e1g1e" as castling with gating on the king's square). However, it does not understand "e1h1e" as a castling move.

[hgm]

This is what I would do for a dedicated S-chess engine as well.

I always preferred the system where off-board to-squares are used to flag special moves. Which, if you use contiguous square-number encoding rather than 0x88 (so that there are no off-board squares), would be equivalent to having only a single bit in the move format to flag the move is special. The code in the to-square then specifies what the move type is, (as an index in a table), and this again is used to obtain the real to-square. This avoids setting aside dedicated space for promotion piece which for most special moves would not be used. This way you can easily afford bigger boards, without needing more than 16 bits. E.g. even with 144 squares, you could use 8-bit from and to-square, and be left with 112 off-board to-squares to encode special moves.

There are an awful lot of gatings, however, quite unlike the number of promotions (which, for a given Pawn, can only have 3 different to-squares). This so-far stopped me from implementing S-Chess in Spartacus. In theory it should be possible, however: with its 8-bit square encoding there would be 192 off-board codes for an 8x8 board. As it uses a 24x10 board layout, two boards would fit next to the used area, and these could be used to encode promotion to H and E, respectively, with a trivial mapping (i.e just adding 8 or 16 to the to-square code of the non-gating move). That consumes 192 codes, and thus leaves 64 in the non-used ranks for other special moves. With 4x5 castlings, 2x3 pawn double pushes, 2x3 e.p. captures that leaves 32 promotions, 16 for each side, by 3 different steps. So there could be 5 different promotion choices. Now that isn;t quite enough, but Spartacus would not search all promotions anyway. I would have to completely reassign all codes, however.

A related question: Sjaak should be able to play Seirawan2880 without any modification, but it doesn't have an algorithm to generate a starting position (it relies on the GUI for that) which is why it doesn't announce this as a possibility. I remember some discussion in the past for "shuffle-FEN" that would tell the GUI which back-rank pieces to shuffle. Did anything come of that? Or should I just bite the bullet and write an algorithm to generate these?

I just checkd the ParseFEN routine, and it seems this did not make it into Win/XBoard yet.

[Ferdy]

Annoying move indeed. Fairy-Max will never do it, and I had to add several lines of code to allow it from the opponent. (Basically pre-correcting the RxK notation to the corresponding K step before doing the normal MakeMove gating at King square, and afterwards moving what appeared on the K square to the R square.)

Even WinBoard is kludgy for this move, regarding notation: in SAN it really writes it as the Rook capturing the King, (e.g. Rxe1/E), which looks awful. We would really need a better notation for it. Gating at King square now is a normal O-O with H or E gating suffix (e.g. O-O/H). One way would be to include a disambiguator behind the suffix (e.g. O-O-O/aH vs. O-O-O/eH), but I really dislike that. Another idea is to use \ in stead of / for the suffix announcer: O-O\H vs O-O/H.

One problem is that the Komodo S-Chess version actually plays this, with black in the opening that it plays against S-Fruit at 2-4min/40 moves TC. (They both play reproducibly.)

Fruit encodes its moves internally as 2 bit special-move flag (normal, e.p., castling, promotion), two bit promotion piece (N, B, R, Q) and 2x 6 bit square number. In S-Fruit I use the promo-piece codes for {N, H, E, Q} instead, upgrading B and R promotion when the user does those. (In theory this can lead to false stalemate perception.) I slipped in some code in move_do() to detect non-null promotion piece in non-promotion moves, and interpret those as gatings (So you can gate H, E or Q, and the code that specifies N on promotion counts as non-gating). This allowed gating to be combined with castlings, and as the castlings are encoded as the King move, the gating code automatically gates at the King square. (The original code tests for castling after the move, and then moves the Rook if there was one, based on the encoded King to-square.)

So what I did is add moves flagged as castlings, but encoding the Rook move in stead of the King move (e.g. a1d1). Then the gating code automatically gates at the Rook square, and the castling code now has to also test for to-square d1/f1/d8/f8 next to c1/g1/c8/g8, and move the King in those cases as extra displacement, rather than the Rook. I did not put it in the move generator yet, so it would never play the move by itself. But when I enter it, it crashes some moves later, so I must have goofed somewhere.

I did not release S-Fruit yet. I wanted to finish and debug it before doing that. But I did not have any opportunity to work on it, last week.

Trying to implement this special castle move, test it and I have this weird behaviour from winboard 4.8.0b. Leonidas-Sigla played a game and Sigla (black) played this castle with gate at rook file h8e8e, but winboard send this move to Leonidas as
108608 >second: h8d8e (which is wrong).
So Leonidas sent to winboard that it is an illegal move, but winboard flagged down Leonidas' claim as false illegal-move claim and eventually awarded the game to Sigla.

Code: Select all

95598 >first : d1f3
silence
95608 <first &#58; # rhbqk2r/ppppbppp/2n2n2/4p3/2B1P3/2N1HQ2/PPPP1PPP/REB1K1NR&#91;e&#93; b KQkq -
95608 <first &#58; # White pieces on-board&#58; wq 1, we 1, wh 1, wr 2, wb 2, wn 2, wp 8
95608 <first &#58; # Black pieces on-board&#58; bq 1, be 0, bh 1, br 2, bb 2, bn 2, bp 8
95608 <first &#58; # Pieces on-hand&#58; we 0, wh 0, be 1, bh 0
95608 <first &#58; # White virgin squares&#58; e1, h1, g1, a1, c1, 
95608 <first &#58; # Black virgin squares&#58; e8, h8, a8, c8, d8, 
95608 <first &#58; # Fifty 7, Hply 9, Repeats 0
95608 <first &#58; # TimeLeft 260040.00 msec  MaxTime 13002.00 msec  AllocatedTime 10154.00 msec
95608 <first &#58;   1    95      0         47 h8e8e
95608 <first &#58;   2    52      1        435 h8e8e f3f5
95608 <first &#58;   3    81      1        927 h8e8e g1e2 e7c5
95608 <first &#58;   4    58      1       3317 e8g8e f3g3 d7d5 c3d5 f6d5 e4d5
95618 <first &#58;   5    92      2       8138 c6a5 g1e2 h8e8e c4b5 a5c4
95638 <first &#58;   6    71      4      12466 c6a5 g1e2 h8e8e c4b5 c7c6 b5a4
95668 <first &#58;   7    58      7      21929 c6a5 g1e2 a5c4 e3c4 h8e8e c4e5 d7d6 e5c4
95738 <first &#58;   8    50     14      46488 c6a5 c4d3 e8g8e g1e2 b7b5 e3f5 b5b4 f5g7 b4c3 g7e8 c3d2 c1d2 f8e8
95808 <first &#58;   9    72     21      73341 c6a5 c4d3 e8g8e g1e2 d7d6 h2h3 c8e6 e1g1 a5c4
96078 <first &#58;  10    44     48     181902 c6a5 c4d3 e8g8e g1e2 d7d6 h2h3 c8e6 e1g1 c7c6 b2b3 b8c7
96598 <first &#58;  11    64    100     377634 h8e8e g1e2 h8g6 e1g1 g6h4 f3g3 f6h5 g3h4 e7h4 e3f5 h4g5 c3d5
97084 <first &#58;  12    60    148     561460 h8e8e g1e2 h8g6 e1g1 g6h4 f3g3 f6h5 g3h4 e7h4 e3f5 h4g5 c3d5 c6e7 d5e7 g5e7 d2d3
98614 <first &#58;  13    79    301    1125475 h8e8e g1e2 d7d6 e1g1 h8g6 h2h3 c6a5 c4d3 c8e6 a2a3 a5c6 g1h2 a7a6
100006 <first &#58;  14    64    440    1645761 h8e8e g1e2 d7d6 e1g1 h8g6 h2h3 c6a5 c4d3 c8e6 a2a3 a5c6 b2b3 g6h4 f3g3 a7a6
108608 <first &#58; # rhbq1rke/ppppbppp/2n2n2/4p3/2B1P3/2N1HQ2/PPPP1PPP/REB1K1NR&#91;-&#93; w KQ -
108608 <first &#58; # Time 13010.00 msec., NPS 371K, NullHits 79.00%&#40;149153&#41;
108608 <first &#58; # MainHash 7.49%&#40;156341&#41;, Pawnhash 91%&#40;3099876&#41;
108608 <first &#58; # bestMove h8e8e, moveScore 64, Fifty 8, Hply 10, Repeats 0
108608 <first &#58; # White pieces on-board&#58; wq 1, we 1, wh 1, wr 2, wb 2, wn 2, wp 8
108608 <first &#58; # Black pieces on-board&#58; bq 1, be 1, bh 1, br 2, bb 2, bn 2, bp 8
108608 <first &#58; # Extensions&#58; Check 134275, Recapture 749, pawnTo7thRank 4081, Ending 0
108608 <first &#58; # Pieces on-hand&#58; we 0, wh 0, be 0, bh 0
108608 <first &#58; 
108608 <first &#58; move h8e8e
FRC castling, 9 2 6 90 2 6
FRC castling, 9 2 6 90 2 6
108608 >second&#58; time 25250
108608 >second&#58; otim 24803
book hit = &#40;NULL&#41;
108608 >second&#58; h8d8e
silence
108608 <second&#58; Illegal move&#58; h8d8e
GameEnds&#40;27, False illegal-move claim, 4&#41;
108608 >first &#58; result 0-1 &#123;False illegal-move claim&#125;
108608 >second&#58; result 0-1 &#123;False illegal-move claim&#125;
108608 >first &#58; force
108608 >first &#58; ping 2

The game.

Code: Select all

[Event "Computer Chess Game"]
[Site "INTEL-PC"]
[Date "2015.01.30"]
[Round "4"]
[White "Leonidas 83 w64 sse42"]
[Black "Sigla v2015.1.2.8"]
[Result "0-1"]
[TimeControl "300+1"]
[Variant "seirawan"]
[Annotator "2. +0.03   2... -0.28"]

1. e4 e5 2. Bc4/H {+0.03/10 14} Nc6/H {-0.28/14 15} 3. He3 {+0.15/11 12}
Nf6 {+0.29/13 14} 4. Nc3/E {+0.10/11 13} Be7 {+0.09/15 14} 5. Qf3
{+0.20/11 11} Rh8xd8=E {+0.64/14 13}
{False illegal-move claim} 0-1

[hgm]

This is weird. So far I could not reproduce anything like it, by performing an RxK capture with the mouse, or typing h8e8e. And the move type-in is supposed to use the same parser as the one used on engine moves. (WinBoard only has one move parser.)

Can you show the PGN of the game (to see what WinBoard thinks the move is there)? Somehow h8e8 mysteriously changes into h8d8. That WinBoard rules a 'False claim' is normal; when legality checking is on, this is its automatic response to any 'Illegal move' claim, because it assumes the moves it sends to the engine are always legal. So it doesn't test them again.

If you have a bit more of the debug file, it could also be helpful.

[Ferdy]

This is weird. So far I could not reproduce anything like it, by performing an RxK capture with the mouse, or typing h8e8e. And the move type-in is supposed to use the same parser as the one used on engine moves. (WinBoard only has one move parser.)

Can you show the PGN of the game (to see what WinBoard thinks the move is there)? Somehow h8e8 mysteriously changes into h8d8. That WinBoard rules a 'False claim' is normal; when legality checking is on, this is its automatic response to any 'Illegal move' claim, because it assumes the moves it sends to the engine are always legal. So it doesn't test them again.

If you have a bit more of the debug file, it could also be helpful.

Game in pgn was already posted. Have a look on the link for complete debug file for this specific game.

http://www.mediafire.com/download/aasyh ... games4.deb

[Ferdy]

This is weird. So far I could not reproduce anything like it, by performing an RxK capture with the mouse, or typing h8e8e. And the move type-in is supposed to use the same parser as the one used on engine moves. (WinBoard only has one move parser.)

I run a tourney using winboard tourney manager when I encounter this problem. Here is 15 start positions that I use.

Download:
http://www.mediafire.com/download/pt17b ... -15pos.pgn

And here is the engine that you may try. Sigla vs Sigla or Sigla vs Lenidas using the start positions above.

Download:
http://www.mediafire.com/download/l87i5 ... .1.2.8.rar

I also encountered h8e8h to h8d8h.

[Ferdy]

I tried to make Sigla able to print fen with virgin squares. Winboard in start position will print like this.

Code: Select all

rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR[HEhe] w KGFDCBQkgfdcbq - 0 1

After inputing some moves,

Code: Select all

[Event "?"]
[Site "?"]
[Date "?"]
[Round "-"]
[White "?"]
[Black "?"]
[Result "*"]
[Variant "seirawan"]

1. d4 d5 2. c4 e6 3. Nc3 Nf6 4. Bg5 Be7 5. e3 O-O 6. Bd3 h6 7. Bh4 c6 8.
Qc2 Nbd7 9. Nf3 dxc4 10. Bxc4 b5 11. Bd3 Bb7 12. O-O Rc8 13. Rad1 Qc7
*
 

and printing the fen,

Code: Select all

2r2rk1/pbqnbpp1/2p1pn1p/1p6/3P3B/2NBPN2/PPQ2PPP/3R1RK1[HEhe] w Hh - 6 14

Winboard still showed virgins in Hh, even if the rooks had already been moved via castlings, perhaps this is a bug. This is not critical since there are no pieces on squares H1 and H8 for them to gate, but still it would be nice to see the Hh removed.

Inputing these moves to latest dev version of Sigla, it will print the fen as.

Code: Select all

d2d4
d7d5
c2c4
e7e6
b1c3
g8f6
c1g5
f8e7
e2e3
e8g8
f1d3
h7h6
g5h4
c7c6
d1c2
b8d7
g1f3
d5c4
d3c4
b7b5
c4d3
c8b7
e1g1
a8c8
a1d1
d8c7
fen
2r2rk1/pbqnbpp1/2p1pn1p/1p6/3P3B/2NBPN2/PPQ2PPP/3R1RK1[HEhe] w - 

-
Sigla can detect the virgin squares by examining move history and the start position.

[hgm]

Winboard still showed virgins in Hh, even if the rooks had already been moved via castlings, perhaps this is a bug. This is not critical since there are no pieces on squares H1 and H8 for them to gate, but still it would be nice to see the Hh removed.

Indeed, this is a bug. I let WinBoard keep a bitmap for each side, as part of the game state, to indicate which of the back-rank pieces are still virgin. I guess I should be more consciencious in clearing that bit; currently I only do that when a from-square is used, because if there is no piece of the right side there it would not consult the bit anyway. But I forgot that it is also used to construct the FEN. Probably I should just have the FEN generator check if there really is a piece.

A more hairy question that came up in connection with Omega Chess is what exactly should be considered the 'back rank'. If you would base an engine-defined variant on seirawan, but would black out most of the squares on the first rank, like in Omega Chess, having the pieces start on the second rank, I guess you would want to gate on the latter. Currently these things are hard-coded in XBoard as 0 and BOARD_HEIGHT-1. I could let it use the ranks where the King starts. But the problem is that not all FENs you load are initial positions. So perhaps I should just take a file in the center of the board, and use the first square on it that is not blacked out as 'gating and castling rank'.

[Evert]

A more hairy question that came up in connection with Omega Chess is what exactly should be considered the 'back rank'. If you would base an engine-defined variant on seirawan, but would black out most of the squares on the first rank, like in Omega Chess, having the pieces start on the second rank, I guess you would want to gate on the latter. Currently these things are hard-coded in XBoard as 0 and BOARD_HEIGHT-1. I could let it use the ranks where the King starts. But the problem is that not all FENs you load are initial positions. So perhaps I should just take a file in the center of the board, and use the first square on it that is not blacked out as 'gating and castling rank'.

It's actually the same in SjaakII. The code that generates the gating mask currently reads

Code: Select all

      bitboard_t<kind> rank = bitboard_t<kind>&#58;&#58;board_north_edge;
      if &#40;side_to_move == WHITE&#41;
         rank = bitboard_t<kind>&#58;&#58;board_south_edge;

so this would have the same problem (well, not for Omega Chess with its mangled board, but for Omicron Chess it would pick the blacked out rank). I'm not sure why I did it like this, rather than through the drop masks that it uses to determine valid drop locations for different sides and piece types.

I actually also just realised that it will not understand the virgin files in a Seirawan FEN. I'll need to be a bit careful with how I handle those because it converts things like KQkq to AHah (or board-size/rook location equivalent) before parsing for compatibility with Chess960. Come to think of it, Omega Chess ranks go up to l, so having "k" in there would be ambiguous with respect to whether it means the back-rank piece on file k is virgin or whether king-side castling is still allowed. I guess that becomes a problem for a Seirawan variant on a 12xN board or larger.

[hgm]

Indeed. The use of KQ should be outlawed on boards with more than 10 files. X is problematic as file indicator in itself, as it is ambiguous with the capture symbol of SAN.