SjaakII 1.0 RC1

[Evert]

I have uploaded a new version of my general variant engine SjaakII, this time with version number 1.0 RC1. If there are no issues, this will become version 1.0.
The main motivation for the change in version number is to make things easier for package managers.

Changes in this release compared to the previous (beta 5) release mainly include compatibility changes so the code can be compiled more easily on Windows (many thanks to Martin Sedlak for contributing those) and many bug fixes to Seirawan chess with respect to the combination of castling+gating moves (it's really amazing how many ways you can mess this up) and the scoring of ungated pieces. Only minor tweaks otherwise, so any differences in playing strength for other variants is probably minor.

Source and OS X binaries at http://www.eglebbk.dds.nl/program/chess-download.html , I will post Linux and Windows binaries later. Benchmark signature 15337549.

[Evert]

Windows 32/64 bit binaries compiled by Martin Sedlak are up, as well as Linux binaries. Link: http://www.eglebbk.dds.nl/program/chess-download.html

[Evert]

I have updated the source, OS X and Linux binary packages for SjaakII to 1.0RC2. Windows binaries will follow later. Files are available from http://www.eglebbk.dds.nl/program/chess-download.html

Changes include many subtle bug fixes in the detection of pinned pieces and check evasion generation, which mainly affected Seirawan Chess. Martin Sedlak found (and fixed) a bug that caused performance under Windows to be much worse than it could have been.

Finally I've fixed some omissions in the variants.txt file, which now includes the definition for castling moves in relevant variants (missing earlier) as well as a description of the various rule flags, including those needed for drop variants. The rule description for Twilight Chess has been moved to the configuration file, and Judkins Shogi (6x6) is also added there, as an example.

[Evert]

Windows compiles are up, courtesy of Martin Sedlak (thanks!).

The download links point to 1.0 RC2b, which is almost the same as 1.0 RC2 I posted earlier except for silencing a load of compiler warnings (and fixing one bug that apparently didn't cause problems on OS X/Linux but would have been potentially crippling on Windows).

As always, please report problems you may encounter.

[hgm]

OK, I played it 10 40/1' games against Sigla,(i.e. variant seirawan), which it lost 7.5-2.5. Then I played it 10 games against Fairy-Max, which it won 8-2. Then I set it playing against S-Fruit, and in the second game it (falsely) complained about an illegal move:

Code: Select all

[Event "Computer Chess Game"]
[Site "ONTWIKKELLAPTOP"]
[Date "2015.02.03"]
[Round "3"]
[White "S-Fruit 2.1 (UCI2WB)"]
[Black "Sjaak II 1.0 RC2b"]
[Result "*"]
[TimeControl "40/60"]
[Variant "seirawan"]

1. Nc3 {+0.16/10} d6 {+0.00/7 0.7} 2. Nf3 {+0.54/10 1.9} Nf6 {-0.49/6 1.1}
3. e4 {+0.51/9 1.7} c6 {+0.39/5 0.8} 4. d4 {+0.85/8 1.3} b5 {+0.14/6 1.6}
5. Bd3 {+1.18/8 2.1} b4 {-0.39/6 1.6} 6. Ne2 {+1.45/8 1.5} h6 {-0.75/6 1.7}
7. O-O/E {+1.73/8 0.9} c5 {-0.77/6 1.7} 8. e5 {+2.76/9 1.3} dxe5
{-0.84/6 1.1} 9. dxe5 {+2.86/8 1.0} Ne4 {-1.10/6 1.8} 10. Bxe4
{+5.82/8 0.8} Qxd1/E {+3.78/7 1.2} {Illegal move Exd1 rejected by second Chess program}

Interesting thing was that when I reloaded the game, to see what would happen if I set Sjaak thinking from the position from scratch, and make a debug log, WinBoard did not allow me to make the move! In stead it was insisting that the Elephant could only move diagonally, as seen from the board markers. Obviously I had legality checking off, and Sjaak must have been poisoning WinBoard with falsehoods!

The debug log shows what happens: Sjaak is using the highlight command (which with legality testing off WinBoard will take as gospel), insisting that the Elephant is a Hawk:

Code: Select all

4285016 >first : memory 260
4285016 >first : new
random
4285016 >first : variant seirawan
4285016 >first : level 40 1 0
4285017 >first : post
4285017 >first : hard
4285017 >first : easy
4285017 >first : ping 6
Impossible move d8d1e, type = 0
4285018 >first : force
....
4285029 <first &#58; pong 6
ForwardInner&#40;20&#41;, current 0, forward 20
PauseEvent&#40;)&#58; pausing 0
4286881 >first &#58; b1c3
4286881 >first &#58; d7d6
4286881 >first &#58; g1f3
4286881 >first &#58; g8f6
4286881 >first &#58; e2e4
4286881 >first &#58; c7c6
4286881 >first &#58; d2d4
4286881 >first &#58; b7b5
4286882 >first &#58; f1d3
4286882 >first &#58; b5b4
4286882 >first &#58; c3e2
4286882 >first &#58; h7h6
4286882 >first &#58; e1g1e
4286882 >first &#58; c6c5
4286882 >first &#58; e4e5
4286882 >first &#58; d6e5
4286882 >first &#58; d4e5
4286883 >first &#58; f6e4
4286883 >first &#58; d3e4
4286883 >first &#58; d8d1e
4293850 >first &#58; lift e1
4293856 <first &#58; highlight 8/8/8/8/1R6/2YY4/3Y4/8
4294380 >first &#58; hover d1
4295100 >first &#58; put d1
4295100 >first &#58; e1d1
4295106 <first &#58; Error &#40;Illegal move or unknown command&#41;&#58; e1d1

[hgm]

And still some questions about the Judkins example:

How does Sjaak know that the parent variant is Shogi? And how that the pieces demote on capture? Is that implied by the "+" promotion? Why are the drop_no_mate and drop_one_file written with the +P rather than the P?

Oh, and "Error (Illegal move ...) is not a compliant way to respond to illegal moves, although XBoard apparently understand it due to its loose (strstr-based) parsing. If you have difficulty recognizing moves from other commands, use feature usermove=1 to make that easy.

[Evert]

How does Sjaak know that the parent variant is Shogi?

Ah, good point: it probably doesn't, which means it'll tell XBoard that the parent variant is "fairy". I'll need to think a bit on the best way to fix that.

And how that the pieces demote on capture? Is that implied by the "+" promotion?

Effectively, yes.
If Sjaak sees that "P" promotes to "+" it will look for a piece called "+P" and set that as the promotion piece for "P", and it will set "+P" to demote to "P" when captured (by default pieces demote to themselves).

Why are the drop_no_mate and drop_one_file written with the +P rather than the P?

Oops.

Oh, and "Error (Illegal move ...) is not a compliant way to respond to illegal moves, although XBoard apparently understand it due to its loose (strstr-based) parsing. If you have difficulty recognizing moves from other commands, use feature usermove=1 to make that easy.

I know. It's not so much difficult as cumbersome, but it's on the list (not very high on the list, admittedly).

[Evert]

OK, I played it 10 40/1' games against Sigla,(i.e. variant seirawan), which it lost 7.5-2.5. Then I played it 10 games against Fairy-Max, which it won 8-2. Then I set it playing against S-Fruit, and in the second game it (falsely) complained about an illegal move:

Code: Select all

[Event "Computer Chess Game"]
[Site "ONTWIKKELLAPTOP"]
[Date "2015.02.03"]
[Round "3"]
[White "S-Fruit 2.1 (UCI2WB)"]
[Black "Sjaak II 1.0 RC2b"]
[Result "*"]
[TimeControl "40/60"]
[Variant "seirawan"]

1. Nc3 {+0.16/10} d6 {+0.00/7 0.7} 2. Nf3 {+0.54/10 1.9} Nf6 {-0.49/6 1.1}
3. e4 {+0.51/9 1.7} c6 {+0.39/5 0.8} 4. d4 {+0.85/8 1.3} b5 {+0.14/6 1.6}
5. Bd3 {+1.18/8 2.1} b4 {-0.39/6 1.6} 6. Ne2 {+1.45/8 1.5} h6 {-0.75/6 1.7}
7. O-O/E {+1.73/8 0.9} c5 {-0.77/6 1.7} 8. e5 {+2.76/9 1.3} dxe5
{-0.84/6 1.1} 9. dxe5 {+2.86/8 1.0} Ne4 {-1.10/6 1.8} 10. Bxe4
{+5.82/8 0.8} Qxd1/E {+3.78/7 1.2} {Illegal move Exd1 rejected by second Chess program}

Interesting thing was that when I reloaded the game, to see what would happen if I set Sjaak thinking from the position from scratch, and make a debug log, WinBoard did not allow me to make the move! In stead it was insisting that the Elephant could only move diagonally, as seen from the board markers. Obviously I had legality checking off, and Sjaak must have been poisoning WinBoard with falsehoods!

The debug log shows what happens: Sjaak is using the highlight command (which with legality testing off WinBoard will take as gospel), insisting that the Elephant is a Hawk:

Code: Select all

4285016 >first : memory 260
4285016 >first : new
random
4285016 >first : variant seirawan
4285016 >first : level 40 1 0
4285017 >first : post
4285017 >first : hard
4285017 >first : easy
4285017 >first : ping 6
Impossible move d8d1e, type = 0
4285018 >first : force
....
4285029 <first &#58; pong 6
ForwardInner&#40;20&#41;, current 0, forward 20
PauseEvent&#40;)&#58; pausing 0
4286881 >first &#58; b1c3
4286881 >first &#58; d7d6
4286881 >first &#58; g1f3
4286881 >first &#58; g8f6
4286881 >first &#58; e2e4
4286881 >first &#58; c7c6
4286881 >first &#58; d2d4
4286881 >first &#58; b7b5
4286882 >first &#58; f1d3
4286882 >first &#58; b5b4
4286882 >first &#58; c3e2
4286882 >first &#58; h7h6
4286882 >first &#58; e1g1e
4286882 >first &#58; c6c5
4286882 >first &#58; e4e5
4286882 >first &#58; d6e5
4286882 >first &#58; d4e5
4286883 >first &#58; f6e4
4286883 >first &#58; d3e4
4286883 >first &#58; d8d1e
4293850 >first &#58; lift e1
4293856 <first &#58; highlight 8/8/8/8/1R6/2YY4/3Y4/8
4294380 >first &#58; hover d1
4295100 >first &#58; put d1
4295100 >first &#58; e1d1
4295106 <first &#58; Error &#40;Illegal move or unknown command&#41;&#58; e1d1

Indeed it does!

Code: Select all

 8r n b q k b   r 
 7p       p p p   
 6    p p   n   p 
 5                
 4  p   P P       
 3      B   N     
 2P P P   N P P P 
 1R   B Q K     R *
  a b c d e f g h 
White holdings [ H: 01 E: 01 ]
Black holdings [ h: 01 e: 01 ]
#[Seirawan] 12w (f)>e1g1e
 8r n b q k b   r *
 7p       p p p   
 6    p p   n   p 
 5                
 4  p   P P       
 3      B   N     
 2P P P   N P P P 
 1R   B Q H R K   
  a b c d e f g h 
White holdings [ E: 01 ]
Black holdings [ h: 01 e: 01 ]
#[Seirawan] 13b (f)>

Looks like a bug in the identification of castling moves on input. Interestingly enough, it works correctly if I enter the move as KxR:

Code: Select all

 8r n b q k b   r 
 7p       p p p   
 6    p p   n   p 
 5                
 4  p   P P       
 3      B   N     
 2P P P   N P P P 
 1R   B Q K     R *
  a b c d e f g h 
White holdings [ H: 01 E: 01 ]
Black holdings [ h: 01 e: 01 ]
#[Seirawan] 12w (f)>e1h1e
 8r n b q k b   r *
 7p       p p p   
 6    p p   n   p 
 5                
 4  p   P P       
 3      B   N     
 2P P P   N P P P 
 1R   B Q E R K   
  a b c d e f g h 
White holdings [ H: 01 ]
Black holdings [ h: 01 e: 01 ]
#[Seirawan] 13b (f)>

[Evert]

Looks like a bug in the identification of castling moves on input.

Ok, that was easier to fix than I expected.

[hgm]

Ah, good point: it probably doesn't, which means it'll tell XBoard that the parent variant is "fairy". I'll need to think a bit on the best way to fix that.

This in itself would not have to be completely fatal, if the engine would completely coach the GUI through highlight commands, result claims and illegal-move responses. It could then make up for XBoard's wrong idea of the promotion zone and the meaning of stalemate and perpetual check, which would have been automatically correct in variant shogi.

But unfortunately Sjaak does not indicate promotion possibilities in the color FEN it sends with the highlight, (magenta), which appears to even suppress promotions of pieces on the last rank, despite the fact that they have a promoted partner indicated as + in the piecetoCharTable. (The highlight overrules XBoard's native idea of when promotions are allowed also in the negative sense, and I guess this is the correct design, e.g. to support the (once erroneously assumed) Chu-Shogi rule that you could not promote with a non-capture the turn after you deferred).

If Sjaak sees that "P" promotes to "+" it will look for a piece called "+P" and set that as the promotion piece for "P", and it will set "+P" to demote to "P" when captured (by default pieces demote to themselves).

OK, this is pretty much how XBoard does it too. In theory there would be the possibility that promoted pieces are indicated with +X in move notation, but would not demote on capture, but I have never seen any example of this. (The '+' notation could be just to avoid a shortage of letters in the alphabet.)


Another request: because for the time being it is likely that there will be a limit to the number of engine-defined variants that XBoard can display in its menus, would it be possible to let Sjaak print the variants from the external variant-definition file before the internally defined ones, so that they have a better chance to appear in the menu?