SjaakII 1.0 RC1

[Evert]

SjaakII version 1.0 RC4 is now available from http://www.eglebbk.dds.nl/program/chess-download.html
Benchmark 18594993

Changes in this version:

• Minor fixes for make install target
• Fix analysis mode, which was broken
• Fix a number of bugs that could cause the board position to be scrambled after castling in Chess960/shuffle variants
• Fix the Betza string generator, which would produce the wrong string for the pawn in Legan's Chess (mF instead of lfmF)
• Keep track of time at each move, for playing timed games in the console.
• New variant: Great Shatranj
• New variant: Superchess
• New variant config file options: specify the maximum number of pieces of a given type (to restrict promotions), setting the number of moves required to claim a repetition draw. Perpetual check is now a separate condition.
• Fix generation of highlight (colour) FEN
• Fix handling of "=" in SAN moves, or to indicate deferred promotion in Shogi.
• SjaakII can now resign and offer draw (and accept draw offers)
• Saner handling of loading/unloading a configuration file
• Optionally change the order in which variants are sent to XBoard: this can be important because it has a limited number of buttons for custom variants.
• Minor tweaks to time-control in drop games: SjaakII sometimes runs out of time on the last ply before time control before it has found a move to play. This now occurs less frequently, and if it does it will still at least play a legal move.
• Some tweaks and updates for the build-in test suites (the movegen tests, the STS suite)

Many thanks to Martin Sedlak for providing Windows binaries. Again, please let me know about bugs and issues.

[hgm]

Progress would need to be carefully defined though. I guess captures, irreversible moves and promotions count as progress, but dropping a piece (to reset the counter) does not. Whether that's enough I don't know, but as a rule-of-thumb it should probably do.

This is a very hard problem in general. We thought about it in the context of Chu Shogi, where you don't even have the problem of drops.

For one, irreversible moves are not progress per se. Even FIDE recognizes this: castling doesn't reset the 50-move counter. Captures of course are progress. But the reason that Pawn moves are considered progress is not because they are irreversible, but because they bring you closer to promotion.

It becomes very hard, however, when reversible pieces can promote. Many Chu Shogi games go into a late end-game where the promotion of the stepper pieces (in particular Gold, which promotes to Rook) becomes essential. But resetting the counter on forward Gold moves, because then shuttling a Gold back and forth between two squares could go on forever, without the counter increasing, while there obviously is no progress at all. Perhaps you would need something like 'location of forward-most promoting piece'. Keep track of the most advanced position since the last capture, and require that you get closer to the zone (or capture something) at least every N moves. Each time you beat your previous record, the counter resets.

The problem in Chu is even worse than in Xiangq, because games will have to be won in the face of forbidden perpetuals. In XQ perpetuals die out pretty quickly. Although when only the 3rd occurence is losing, you can give 3 checks with a Rook before having to play something else, and allow progress, after which you can stall another 8 ply. So things just develop 10 times slower than normal, and by discounting checks and evasions in the count you can make thempointless.

But in Chu there are Queens, and the board is huge. That means it takes ages before you have exhausted the non-repeating checking opportunities. An end-game of 2 Tigers against a Queen is theoretically won, because the tigers will eventually promote to Stags, which move along files like Rooks, so that a pair of them can easily force mate. In FIDE KRRKQ is draw, however, because the Q starts to deliver a perpetual. In Chu you just ride it out until he cannot check anymore without repeating. But it can take easily a thousand of moves when you have to ride out 30 checks after every move of your winning plan...

[hgm]

The other issue is that Sjaak will consider the gold to have mate potential - which is correct, as long as the defending king is in front of the gold. It doesn't take that into account. If it did, it might be enough to convince it to keep a silver around to avoid the loss of mate potential. That requires quite a bit of changes to the code though (as well as the rule of thumb that says that > 2 pieces are considered mate potential if they're not all color-bound on the same colour).

I don't think that is the problem. KGK is generally won upto 14x14 boards, IIRC. I also don't think that Silvers would do much better against a wall of Gold when they have to fight backwards, even though they have more backward power. The problem with impasse is that you can constantly replenish the defenders in your King castle by dropping Pawns in it, which promote on the next move. An attacker can never keep up with this supply.

[Evert]

I have updated the Windows binaries to a newer compile. Consider downloading them again if you already did so before.

[Evert]

But in Chu there are Queens, and the board is huge. That means it takes ages before you have exhausted the non-repeating checking opportunities. An end-game of 2 Tigers against a Queen is theoretically won, because the tigers will eventually promote to Stags, which move along files like Rooks, so that a pair of them can easily force mate. In FIDE KRRKQ is draw, however, because the Q starts to deliver a perpetual. In Chu you just ride it out until he cannot check anymore without repeating. But it can take easily a thousand of moves when you have to ride out 30 checks after every move of your winning plan...

I wonder if a variation of the following idea can be made viable:

1. Detect that there is a mate-threat from the enemy pieces. Say by bolting everything in place, apart from the enemy pieces and the own king (take care that captures and safe interpositions should still be allowed). Basically this get rid of the spite checks by construction, as well as pointless wandering with the king. This is probably something that only needs to be done for a particular material combination once (at the root, say).
2. If we are under mate-threat by enemy pieces and perpetual check is not allowed, we are probably lost. Do a shallow QS-like search that tries to capture a piece (disallow checking moves by the defending side after a certain depth, basically prune them as likely to be futile)
3. Hang in there for a little while, to see if a tactical shot that we overlooked does present itself.
4. Resign.

I suppose that at the end of the day there is no way to make the engine not try to push the mate over the horizon, but a special mate-search (where spite checks are disallowed) that defeats all non-checking moves can probably help a bit with at least seeing that the position is lost. Perhaps that's too specific for this particular scenario though.

[Evert]

I don't think that is the problem. KGK is generally won upto 14x14 boards, IIRC. I also don't think that Silvers would do much better against a wall of Gold when they have to fight backwards, even though they have more backward power. The problem with impasse is that you can constantly replenish the defenders in your King castle by dropping Pawns in it, which promote on the next move. An attacker can never keep up with this supply.

Is it too coarse to drag the score down to draw-ish if the enemy king is sitting comfortable in his own promotion zone, surrounded by either his own pieces or with the other side having a load of pieces in reserve?

Or perhaps, given the general forward-nature of Shogi pieces, penalise positions where the enemy king has moved past the bulk (all?) of your army (this needs to be done carefully because you don't want to encourage the program to walk its own king into the enemy camp voluntarily)?

[hgm]

OK, this is a bit of a complex story:

I was still working on some backlogged complaints from Keith, to see if they were XBoard problems or Sjaak problems. This was in the Euro-Shogi, which I defined in the variants.txt as follows:

Code: Select all

#############
# EuroShogi #
#############
Variant: EuroShogi (8x8)
Board: 8x8
FEN: "1nbgkgn1/1r4b1/pppppppp/8/8/PPPPPPPP/1B4R1/1NGKGBN1"
XBoard pieces: "PNBR.....G.++++Kpnbr.....g.++++k"
XBoard parent: "shogi"
Zone: white_promotion = a8,b8,c8,d8,e8,f8,g8,h8,a7,b7,c7,d7,e7,f7,g7,h7,a6,b6,c6,d6,e6,f6,g6,h6
Zone: black_promotion = a3,b3,c3,d3,e3,f3,g3,h3,a2,b2,c2,d2,e2,f2,g2,h2,a1,b1,c1,d1,e1,f1,g1,h1

# Define the pieces
Piece: Knight
Move: aleap (1,2)|(-1,2)|(1,0)|(-1,0)
Symbol: "N", "N,n"
Promotion: white_promotion, black_promotion, "+"
Value: 250

Piece: Bishop
Move: slide (D,A)
Symbol: "B", "B,b"
Promotion: white_promotion, black_promotion, "+"
Value: 575

Piece: Gold general
Move: aleap (1,0)|(-1,0)|(0,1)|(0,-1)|(1,1)|(-1,1)
Symbol: "G", "G,g"
Value: 450

Piece: Rook
Move: slide (H,V)
Symbol: "R", "R,r"
Promotion: white_promotion, black_promotion, "+"
Value: 650

Piece: Pawn
Move: step N
Symbol: "P", "P,p"
Promotion: white_promotion, black_promotion, "+"
Flags: drop_no_mate, drop_one_file
Value: 80

Piece: Promoted Knight
Move: aleap (1,0)|(-1,0)|(0,1)|(0,-1)|(1,1)|(-1,1)
Symbol: "+N", "+N,+n"
Value: 500

Piece: Dragon Horse
Move: slide (D,A)
Move: leap (1, 0)
Symbol: "+B", "+B,+b"
Value: 825

Piece: Dragon King
Move: slide (H,V)
Move: leap (1, 1)
Symbol: "+R", "+R,+r"
Value: 950

Piece: Promoted Pawn
Move: aleap (1,0)|(-1,0)|(0,1)|(0,-1)|(1,1)|(-1,1)
Symbol: "+P", "+P,+p"
Value: 530


Piece: King
Move: leap (0,1)|(1,1)
Symbol: "K", "K,k"
Flags: royal

Rule: keep capture, allow drops
Rule: repeat4 = draw

Part of the illegal-move problems could be traced to the XBoard default assumption that a promotion zone on an 8-rank Shogi board is 2 ranks deep, which is wrong for Euro-Shogi, where it is 3 ranks. So to not flag promotions on 6th-rank as illegal, legality testing has to be off. There still was an illegal move e6g8+ in a debug excerpt though, for which I did not have the full game. So I started playing some eng-eng games myself. The second did end in an illegal move:

Code: Select all

[Event "Computer Chess Game"]
[Site "hgm-xboard"]
[Date "2015.02.18"]
[Round "-"]
[White "Sjaak II 1.0"]
[Black "Sjaak II 1.0"]
[Result "1-0"]
[TimeControl "40/60"]
[Variant "euroshogi"]
[VariantMen "P:fW;N:sWffN;B:B;R:R;G:WfF;+P:WfF;+N:WfF;+B:BW;+R:RF;K:K;+p:WfF;+n:WfF;+b:BW;+r:RF"]
[FEN "1nbgkgn1/1r4b1/pppppppp/8/8/PPPPPPPP/1B4R1/1NGKGBN1[-] w 0 1"]
[SetUp "1"]

{--------------
. n b g k g n .
. r . . . . b .
p p p p p p p p
. . . . . . . .
. . . . . . . .
P P P P P P P P
. B . . . . R .
. N G K G B N .
white to play
--------------}
1. f4 {+0.06/8} c5 {-0.10/8 1.3} 2. Rf2 {+0.12/9 1.3} Re7 {-0.06/9 1.3} 3.
Bg2 {+0.08/9 1.5} e5 {-0.08/8 1.0} 4. Kc2 {+0.08/8 1.5} Kf7 {-0.26/6 1.1}
5. Nf3 {+0.19/7 1.3} Ke8 {-0.40/6 0.9} 6. Ge2 {+0.63/7 2.8} b5
{-0.47/6 1.1} 7. c4 {+0.42/7 1.5} cxc4 {-0.47/6 1.4} 8. Nxe5 {+0.47/5 1.1}
P@e6 {+1.40/6 1.6} 9. P@c5 {-1.43/6 1.1} Rc7 {+2.45/6 1.7} 10. Be4
{-2.45/5 0.9} exe5 {+1.09/5 1.1} 11. Bxg6+ {-2.48/5 1.4} N@f7 {+2.27/5 1.6}
12. Bxe5 {-2.27/5 1.2} Ke7 {+3.30/6 1.7} 13. Bd4 {-2.79/5 0.8} Bxh3+
{+3.59/5 0.9} 14. f5 {-2.83/5 1.5} fxf5 {+2.83/4 1.2} 15. +Bxf5
{-4.04/4 0.9} +Bxf5 {+3.93/5 1.1} 16. Rxf5 {-3.48/5 1.9} B@h3 {+4.37/4 0.9}
17. B@g6 {-4.37/3 1.3} Bxd4 {+4.37/4 1.0} 18. dxd4 {-10.14/4 1.2} Gg7
{+6.77/4 4} 19. B@h7 {-9.46/3 1.0} Nf8 {+10.41/4 1.1} 20. Bxf7=
{-9.50/5 2.4} Gxh7 {+11.04/4 2.7} 21. N@g4 {-10.90/4 3} Gg6 {+11.04/3 1.0}
22. Rf2 {-11.20/4 1.0} Rxc5 {+11.56/5 9} 23. Kd3 {-9.97/3 0.8} B@f5
{+12.62/3 1.6} 24. Rxf5 {-13.80/2 1.6} Gxf5 {+17.99/3 0.7} 25. B@b6
{-12.77/2 1.6}
{Xboard: Forfeit due to invalid move: g6f5 (g6f5 via ^0) res=24} 1-0

Note that this might be a red herring, as I think I was still using the version to which you published the link here, and not the official RC4. So if it looks like the result of a familiar bug, you have already fixed, just ignore this.

The illegal move is actually a repetition of the previous move; it seems Sjaak fails to find a move here, and just repeats the previous one it played. The thinking output was:

Code: Select all

dep	score	nodes	time	(not shown:  tbhits	knps	seldep)
  2	  0.00 	196658	0:01.32	25. ... 

Then I upgraded to RC4, and again played a few games. No illegal moves now, but I did see something suspect:

Code: Select all

[Event "Computer Chess Game"]
[Site "hgm-xboard"]
[Date "2015.02.18"]
[Round "-"]
[White "Sjaak II 1.0 RC4"]
[Black "Sjaak II 1.0 RC4"]
[Result "0-1"]
[TimeControl "40/60"]
[Variant "euroshogi"]
[VariantMen "P:fW;N:sWffN;B:B;R:R;G:WfF;+P:WfF;+N:WfF;+B:BW;+R:RF;K:K;+p:WfF;+n:WfF;+b:BW;+r:RF"]
[FEN "1nbgkgn1/1r4b1/pppppppp/8/8/PPPPPPPP/1B4R1/1NGKGBN1[-] w 0 1"]
[SetUp "1"]

{--------------
. n b g k g n .
. r . . . . b .
p p p p p p p p
. . . . . . . .
. . . . . . . .
P P P P P P P P
. B . . . . R .
. N G K G B N .
white to play
--------------}
1. Kc2 {+0.00/8} f5 {-0.10/8 1.5} 2. g4 {-0.05/8 1.5} Bf6 {-0.05/8 1.1} 3.
c4 {-0.10/7 0.9} e5 {+0.07/7 0.9} 4. Rf2 {-0.03/8 1.1} Be6 {-0.07/8 1.6} 5.
f4 {+0.19/9 2.0} fxf4 {-0.18/8 1.5} 6. Rxf4 {-0.01/8 1.2} P@f5
{+0.02/7 0.9} 7. Rf2 {+0.06/7 0.9} b5 {-0.12/7 1.5} 8. Bc3 {+0.00/7 1.6}
Nc8 {-0.59/6 1.4} 9. Nf3 {+0.13/7 2.6} e4 {-0.13/7 1.5} 10. exe4
{+0.34/7 1.4} Bxc3+ {-0.81/6 0.9} 11. Nxc3 {+0.12/6 1.6} Nf6 {-1.02/6 1.6}
12. B@e5 {+0.71/6 1.4} B@g7 {-0.80/6 1.1} 13. g5 {+1.39/6 1.4} gxg5
{-1.39/6 1.8} 14. Re2 {+0.45/6 1.2} g4 {-0.67/6 0.9} 15. Ng5 {+0.47/6 1.6}
Gg8 {-0.34/5 1.1} 16. Kd1 {+0.34/5 1.8} Kd7 {-0.19/6 1.6} 17. Gc2
{+0.15/5 0.9} b4 {-0.27/5 1.0} 18. bxb4 {+0.24/4 1.7} Rxb4 {-0.87/6 1.4}
19. Gb3 {+0.26/6 1.5} Rb7 {-0.56/6 1.7} 20. P@b5 {+0.73/5 1.9} Gc7
{-0.57/5 1.5} 21. Kc2 {+0.54/6 1.6} P@b6 {-0.59/5 0.9} 22. b5xb6=+
{+0.47/6 1.2} Nxb6 {+0.40/6 2.6} 23. Nb5 {-0.40/5 1.5} Nxc4 {+0.40/4 1.2}
24. Nxc7+ {+0.67/3 1.6} Kxc7 {-2.73/3 1.2} 25. Re3 {+2.18/2 1.6} Nb4
{-0.49/2 1.8} 26. Gxb4 {+0.74/2 0.8} Rxb4 {+2.02/4 3} 27. G@c3
{-2.29/3 1.6} G@b3 {+5.49/5 2.7} 28. Kc1 {-5.59/5 1.6} Gxc3 {+15.15/5 9}
29. N@c2 {-15.90/4 9} Rb3+ {+15.90/3 0.5} 30. Gd2 {-18.52/5 0.8} G@b1
{+21.15/5 1.4} 31. Kd1 {-18.52/2} N@d5 {+21.15/5 0.8} 32. Re2
{-21.15/4 0.9} Nxe5 {+21.15/3 0.4} 33. exe5 {-22.44/5 0.8} Gxd2
{+22.14/5 0.9} 34. Nxd2 {-20.36/5 0.9} G@c1 {+20.65/5 0.6} 35. Ke1
{-20.26/2} Bd7 {+20.06/5 1.3} 36. N@e7 {-18.05/5 0.7} Be8 {+16.24/5 0.9}
37. e5e6=+ {-13.58/5 1.5} Nxe6 {+16.88/4 0.8} 38. Rxe6+ {-16.50/4 1.0} B@g3
{+14.99/4 0.8} 39. N@f2 {-14.64/4 2.6} P@e2 {+14.03/4 0.9} 40. Bxe2
{-13.11/3 0.7} B3e5+ {+10.79/3 0.8} 41. G@d7 {-7.99/5 0.8} Kb8
{+10.11/6 2.7} 42. +Rxe5 {-10.11/6 0.9} Bxe5 {+9.81/6 1.5} 43. B@c7
{-8.96/5 2.3} Ka8 {+8.66/5 1.5} 44. Gxe8 {-8.96/5 1.5} R@g1 {+8.96/4 1.1}
45. P@f1 {-8.96/3 0.8} g4g3=+ {+9.65/4 0.8} 46. Nxf5 {-9.18/4 1.1} +Pxf2
{+12.85/5 0.8} 47. Kxf2 {-9.18/2} Rg3+ {+12.75/5 1.6} 48. Ke1 {-9.18/2}
+Re3 {+12.39/4 1.2} 49. Nxe5 {-7.64/4 1.7} N@f3# {+159.99/2}
{Black mates} 0-1

The suspect thing is that it does not see mated-in-1 coming in a 4-ply search. The thinking output was:

Code: Select all

dep	score	nodes	time	(not shown:  tbhits	knps	seldep)
  4	 -7.64 	442371	0:01.68	49. Nxe5 +xe5 50. Nd7+ 
  3	 -1.26 	7857    0:00.06	49. Nxe5 +xe5 50. Nd7+ 
  2	 -1.26 	518     0:00.00	49. Nxe5 +xe5 50. Nd7+ 

dep	score	nodes	time	(not shown:  tbhits	knps	seldep)
  2	+159.99 3082    0:00.02	49. ... N@f3 

This sort of reproduces in a virgin search in the position where it fails to detect the mated-in-1. Strange thing is that it does switch to Pf2 to defend against the mate already at 3 ply in its PV, but it does not play it! It still played Nxe5?

Code: Select all

dep	score	nodes	time	(not shown:  tbhits	knps	seldep)
  3	 -14.18 458770	0:01.64	49. Pf2 Bh2+ 50. Pd4 
  2	 -1.26 	452     0:00.00	49. Nxe5 +xe5 50. Nd7+ 

This was at 40 moves/min; when I gave it more time (40/10', again in a virgin search) it does switch to Pf2 and actually plays it:

Code: Select all

dep	score	nodes	time	(not shown:  tbhits	knps	seldep)
  4	 -26.02 	3.11M  	0:11.48	49. Pf2 Bc3+ 50. Bf1 +xd2 
  3	 -1.26 	7119    	0:00.07	49. Nxe5 +xe5 50. Nd7+ 
  2	 -1.26 	514      	0:00.00	49. Nxe5 +xe5 50. Nd7+ 

Is this a "play the best move of the previous iteration when the score drops too much" trick in combination with some search explosion on check extensions? (4 ply in 11 sec is a bit meagre...)

Also note there is a cosmetic problem in the PV notation: +xe5 probably means +Rxe5 here.

Some other remarks:

* The Judkins example now does contain a Rule: repeat4 = draw, but it doesn't mention anything about perpetuals yet. Is this an omission or still awaiting implementation?

* Is it possible to indicate promotion is mandatory? In Euro-Shogi it is. In regular Shogi it only is when the piece would have no moves. Or, in line with the notation in Chess where you say for Pawn "NBRQ", shouldn't Shogi promotions be denoted as "+=" when they are optional, and "+" when they are mandatory?

* It sees the mandatory P and N promotions are now implied even when there is a possibility to defer (which currently also seems implied). This could stay that way. Or it could be made explicit by defining rank7, 8 and 9 as separate zones, and for Pawn specify "+=" for promotion in rank7 and 8, and only "+" on rank9. Does Sjaak already allow such position-dependent promotion options in general, or can you have only one promotion rule per piece?

* It seems that in Dobutsu Shogi it is allowed to drop a Pawn on the last rank, turning it into dead wood. I suppose Sjaak uses the heuristic that you cannot drop where you have no moves. Could this also be made configurable? (Wish-list item!)

[myfish]

* It seems that in Dobutsu Shogi it is allowed to drop a Pawn on the last rank, turning it into dead wood. I suppose Sjaak uses the heuristic that you cannot drop where you have no moves. Could this also be made configurable? (Wish-list item!)

Yes please.

On another note, everytime a new sjaakII version comes through, I'm having to change piece names for svg files.

If I remember RC2, it was one set, then HGM told me about the 'parent shogi' line coming in under the xboard pieces declarations in 'variants.txt' and all was good.

However, RC4 broke all that and I've had to rename pieces again.
My understanding of xboard pieces where they were stored in an array that doesn't move?

I've fixed it now and never have any of the pieces not 'moved' as described. Just the names change.

Right now, trying to get gorogoro and the handicap version, dobutsu and now euroshogi is great. It'll either end in sunshine or tears I guess. I vote for the former of course.

[Evert]

OK, this is a bit of a complex story:

[…]

Part of the illegal-move problems could be traced to the XBoard default assumption that a promotion zone on an 8-rank Shogi board is 2 ranks deep, which is wrong for Euro-Shogi, where it is 3 ranks. So to not flag promotions on 6th-rank as illegal, legality testing has to be off. There still was an illegal move e6g8+ in a debug excerpt though, for which I did not have the full game. So I started playing some eng-eng games myself. The second did end in an illegal move:

[…]

Note that this might be a red herring, as I think I was still using the version to which you published the link here, and not the official RC4. So if it looks like the result of a familiar bug, you have already fixed, just ignore this.

The illegal move is actually a repetition of the previous move; it seems Sjaak fails to find a move here, and just repeats the previous one it played. The thinking output was:

Code: Select all

dep	score	nodes	time	(not shown:  tbhits	knps	seldep)
  2	  0.00 	196658	0:01.32	25. ... 

Yes, this is a known issue in the previous release, and it should be fixed in RC4.

The problem occurs when Sjaak exceeds the thinking time it has allocated for this move before it has finished its 1-ply search. It used to operate under the assumption that it could always do this, but when it didn't it would try to play the move that was recorded as "best move", which is the one from the last search.
I've made a couple of changes to try to beat down on this problem: in RC 4, Sjaak allocates more time for the first iteration (it does its best to finish it) and I do much more aggressive pruning of drop moves than I normally do. If that's still not enough, it will try to play a move from the hash table and if that fails, a random legal move.
Of course it may well be screwed after that, but at least it shouldn't play illegal moves anymore.

At some point I should look at my search again to figure out why it's taking such a long time. Perhaps staged move generation will really pay off here (with drops only generated if needed, I currently generate all of them up front).

Then I upgraded to RC4, and again played a few games. No illegal moves now, but I did see something suspect:

Code: Select all

[Event "Computer Chess Game"]
[Site "hgm-xboard"]
[Date "2015.02.18"]
[Round "-"]
[White "Sjaak II 1.0 RC4"]
[Black "Sjaak II 1.0 RC4"]
[Result "0-1"]
[TimeControl "40/60"]
[Variant "euroshogi"]
[VariantMen "P:fW;N:sWffN;B:B;R:R;G:WfF;+P:WfF;+N:WfF;+B:BW;+R:RF;K:K;+p:WfF;+n:WfF;+b:BW;+r:RF"]
[FEN "1nbgkgn1/1r4b1/pppppppp/8/8/PPPPPPPP/1B4R1/1NGKGBN1[-] w 0 1"]
[SetUp "1"]

{--------------
. n b g k g n .
. r . . . . b .
p p p p p p p p
. . . . . . . .
. . . . . . . .
P P P P P P P P
. B . . . . R .
. N G K G B N .
white to play
--------------}
1. Kc2 {+0.00/8} f5 {-0.10/8 1.5} 2. g4 {-0.05/8 1.5} Bf6 {-0.05/8 1.1} 3.
c4 {-0.10/7 0.9} e5 {+0.07/7 0.9} 4. Rf2 {-0.03/8 1.1} Be6 {-0.07/8 1.6} 5.
f4 {+0.19/9 2.0} fxf4 {-0.18/8 1.5} 6. Rxf4 {-0.01/8 1.2} P@f5
{+0.02/7 0.9} 7. Rf2 {+0.06/7 0.9} b5 {-0.12/7 1.5} 8. Bc3 {+0.00/7 1.6}
Nc8 {-0.59/6 1.4} 9. Nf3 {+0.13/7 2.6} e4 {-0.13/7 1.5} 10. exe4
{+0.34/7 1.4} Bxc3+ {-0.81/6 0.9} 11. Nxc3 {+0.12/6 1.6} Nf6 {-1.02/6 1.6}
12. B@e5 {+0.71/6 1.4} B@g7 {-0.80/6 1.1} 13. g5 {+1.39/6 1.4} gxg5
{-1.39/6 1.8} 14. Re2 {+0.45/6 1.2} g4 {-0.67/6 0.9} 15. Ng5 {+0.47/6 1.6}
Gg8 {-0.34/5 1.1} 16. Kd1 {+0.34/5 1.8} Kd7 {-0.19/6 1.6} 17. Gc2
{+0.15/5 0.9} b4 {-0.27/5 1.0} 18. bxb4 {+0.24/4 1.7} Rxb4 {-0.87/6 1.4}
19. Gb3 {+0.26/6 1.5} Rb7 {-0.56/6 1.7} 20. P@b5 {+0.73/5 1.9} Gc7
{-0.57/5 1.5} 21. Kc2 {+0.54/6 1.6} P@b6 {-0.59/5 0.9} 22. b5xb6=+
{+0.47/6 1.2} Nxb6 {+0.40/6 2.6} 23. Nb5 {-0.40/5 1.5} Nxc4 {+0.40/4 1.2}
24. Nxc7+ {+0.67/3 1.6} Kxc7 {-2.73/3 1.2} 25. Re3 {+2.18/2 1.6} Nb4
{-0.49/2 1.8} 26. Gxb4 {+0.74/2 0.8} Rxb4 {+2.02/4 3} 27. G@c3
{-2.29/3 1.6} G@b3 {+5.49/5 2.7} 28. Kc1 {-5.59/5 1.6} Gxc3 {+15.15/5 9}
29. N@c2 {-15.90/4 9} Rb3+ {+15.90/3 0.5} 30. Gd2 {-18.52/5 0.8} G@b1
{+21.15/5 1.4} 31. Kd1 {-18.52/2} N@d5 {+21.15/5 0.8} 32. Re2
{-21.15/4 0.9} Nxe5 {+21.15/3 0.4} 33. exe5 {-22.44/5 0.8} Gxd2
{+22.14/5 0.9} 34. Nxd2 {-20.36/5 0.9} G@c1 {+20.65/5 0.6} 35. Ke1
{-20.26/2} Bd7 {+20.06/5 1.3} 36. N@e7 {-18.05/5 0.7} Be8 {+16.24/5 0.9}
37. e5e6=+ {-13.58/5 1.5} Nxe6 {+16.88/4 0.8} 38. Rxe6+ {-16.50/4 1.0} B@g3
{+14.99/4 0.8} 39. N@f2 {-14.64/4 2.6} P@e2 {+14.03/4 0.9} 40. Bxe2
{-13.11/3 0.7} B3e5+ {+10.79/3 0.8} 41. G@d7 {-7.99/5 0.8} Kb8
{+10.11/6 2.7} 42. +Rxe5 {-10.11/6 0.9} Bxe5 {+9.81/6 1.5} 43. B@c7
{-8.96/5 2.3} Ka8 {+8.66/5 1.5} 44. Gxe8 {-8.96/5 1.5} R@g1 {+8.96/4 1.1}
45. P@f1 {-8.96/3 0.8} g4g3=+ {+9.65/4 0.8} 46. Nxf5 {-9.18/4 1.1} +Pxf2
{+12.85/5 0.8} 47. Kxf2 {-9.18/2} Rg3+ {+12.75/5 1.6} 48. Ke1 {-9.18/2}
+Re3 {+12.39/4 1.2} 49. Nxe5 {-7.64/4 1.7} N@f3# {+159.99/2}
{Black mates} 0-1

The suspect thing is that it does not see mated-in-1 coming in a 4-ply search. The thinking output was:

Code: Select all

dep	score	nodes	time	(not shown:  tbhits	knps	seldep)
  4	 -7.64 	442371	0:01.68	49. Nxe5 +xe5 50. Nd7+ 
  3	 -1.26 	7857    0:00.06	49. Nxe5 +xe5 50. Nd7+ 
  2	 -1.26 	518     0:00.00	49. Nxe5 +xe5 50. Nd7+ 

dep	score	nodes	time	(not shown:  tbhits	knps	seldep)
  2	+159.99 3082    0:00.02	49. ... N@f3 

This sort of reproduces in a virgin search in the position where it fails to detect the mated-in-1. Strange thing is that it does switch to Pf2 to defend against the mate already at 3 ply in its PV, but it does not play it! It still played Nxe5?

Code: Select all

dep	score	nodes	time	(not shown:  tbhits	knps	seldep)
  3	 -14.18 458770	0:01.64	49. Pf2 Bh2+ 50. Pd4 
  2	 -1.26 	452     0:00.00	49. Nxe5 +xe5 50. Nd7+ 

This was at 40 moves/min; when I gave it more time (40/10', again in a virgin search) it does switch to Pf2 and actually plays it:

Code: Select all

dep	score	nodes	time	(not shown:  tbhits	knps	seldep)
  4	 -26.02 	3.11M  	0:11.48	49. Pf2 Bc3+ 50. Bf1 +xd2 
  3	 -1.26 	7119    	0:00.07	49. Nxe5 +xe5 50. Nd7+ 
  2	 -1.26 	514      	0:00.00	49. Nxe5 +xe5 50. Nd7+ 

Is this a "play the best move of the previous iteration when the score drops too much" trick in combination with some search explosion on check extensions? (4 ply in 11 sec is a bit meagre…)

I'll have a look to figure out what's going on here. Something does seem off.

Also note there is a cosmetic problem in the PV notation: +xe5 probably means +Rxe5 here.

Yes. I'll fix that too.

* The Judkins example now does contain a Rule: repeat4 = draw, but it doesn't mention anything about perpetuals yet. Is this an omission or still awaiting implementation?

Omission.

* Is it possible to indicate promotion is mandatory? In Euro-Shogi it is. In regular Shogi it only is when the piece would have no moves. Or, in line with the notation in Chess where you say for Pawn "NBRQ", shouldn't Shogi promotions be denoted as "+=" when they are optional, and "+" when they are mandatory?

Sjaak uses per-piece type (and per-side) bitmasks to indicate promotion zones. It has two of them: mandatory and optional promotion zones, which are constructed from the "promotion zone" you specify using a rule-of-thumb: promotions are mandatory, unless the piece would still be able to move from its new square, in which case it can defer the promotion.

Making promotions mandatory just requires overriding the optional promotion zone bitmasks - but it can't be done from the config file.
This particular case though ("promotions are always mandatory") would be easy to handle with a special rule.

* It sees the mandatory P and N promotions are now implied even when there is a possibility to defer (which currently also seems implied). This could stay that way. Or it could be made explicit by defining rank7, 8 and 9 as separate zones, and for Pawn specify "+=" for promotion in rank7 and 8, and only "+" on rank9. Does Sjaak already allow such position-dependent promotion options in general, or can you have only one promotion rule per piece?

Something like that is probably the way to go, I just need to keep track of whether the default rule should be applied or not.

* It seems that in Dobutsu Shogi it is allowed to drop a Pawn on the last rank, turning it into dead wood. I suppose Sjaak uses the heuristic that you cannot drop where you have no moves. Could this also be made configurable? (Wish-list item!)

Yes. The drop-zone is another per-piece type bitmask.
I can think of two ways to handle this case: a special piece-flag that indicates that the "graveyard" (where the piece would have no legal moves) should not be removed from the drop-zone, and a general method that allows you to specify the drop-zone completely by hand. Perhaps both would be desirable.

There is actually another set of bitmasks, the "prison" that identifies what squares on the board a piece is allowed to move to. This is used to limit the moves of kings, guards and elephants in Xiangqi. I should probably expose that in the config file as well.

[hgm]

One more cosmetic problem: with "Rule: repeat4 = draw" Sjaak still prints "3-fold repetition" as a reason when it claims the draw.

Just to be sure: the perpetual is always defined with the same number of moves as the repeat rule? Or do you have to write thigs like perpetual4 = illegal?