Grande Acedrex

[hgm]

What I don't like in Fairy-Max' Grande Acedrex play is that it freezes the King on the initial square. Castling is recognized, and gets a bonus large enough to overcome the penalty any King move gets (which again overcomes the tendency of the King to centralize). But an initial 2-step move is not recognized as castling. So it falls under the effective King-move ban, and it won't move the King from its starting square until the end-game starts, or check forces it away. (And then it usually takes the 2-step leap.)

I guess I should recognize all virgin King moves, and give them a bonus, not just castlings. But a problem is that the King, once moving, tries to centralize, and that even after a sideway initial leap it is still pretty far from a safe corner. And it is more likely to walk back to the center than further into the corner... So I should flip the sign of the centralization weight in the opening, so that Kings seek the corners. Which is dangerous, as it encourages the King to lock in the Rook in variants with castling. So perhaps it should only be done in variants without castling, in the setup code. Although Shatranj also is without castling, and locking in your Rook there is quite disastrous. So perhaps it should be made dependent on the Pawns starting on 2nd rank.

[Evert]

I just spotted an illegal move claim (by XBoard) when I did a quick check on a series of test games. It looks bogus to me. The full game is

Code: Select all

[Event "Computer Chess Game"]
[Site "vivaine.local"]
[Date "2016.01.13"]
[Round "1"]
[White "Postduif 0.12"]
[Black "Fairy-Max 4.8V"]
[Result "0-1"]
[TimeControl "40/20"]
[Variant "grande-acedrex"]
[VariantMen "P:fmWfcF;C:B;R:R;A:FyafsF;U:NmpafsyafW;G:Z;L:HC;K:KimDimA"]
[FEN "rlugcakcgulr/12/12/pppppppppppp/12/12/12/12/PPPPPPPPPPPP/12/12/RLUGCAKCGULR w Kk - 0 1"]
[SetUp "1"]

{--------------
r l u g c a k c g u l r
. . . . . . . . . . . .
. . . . . . . . . . . .
p p p p p p p p p p p p
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
P P P P P P P P P P P P
. . . . . . . . . . . .
. . . . . . . . . . . .
R L U G C A K C G U L R
white to play
--------------}
1. Uf3 {+0.08/9} Ud10 {+0.36/5 0.7} 2. h5 {+0.12/8 0.5} Ui10 {-0.13/4 0.4}
3. Ujg5 {+0.11/7 0.3} Cf11 {-0.04/4 0.4} 4. Ck7 {+0.11/7 0.3} j8
{+0.22/5 0.3} 5. Cj6 {+0.06/7 0.3} Le11 {+0.45/5 0.7} 6. Gg3 {+0.07/7 0.3}
Lf8 {+0.22/4 0.2} 7. Ue6 {+0.10/8 0.5} Uf7 {-0.21/4 0.4} 8. Gd5
{+0.17/7 0.5} Li8 {-0.48/4 0.2} 9. Gg7 {+0.15/6 0.3} Ug11 {-0.30/4 1.4} 10.
Gl3 {+0.21/7 0.6} Ud8 {+0.03/3 0.2} 11. Ufg5 {+0.05/7 0.3} Lf8
{+0.47/5 0.3} 12. Uxd8 {+0.01/8 0.3} cxd8 {+0.30/6 0.4} 13. Uf3
{+0.06/8 0.6} Li8 {+0.16/5 1.9} 14. Ae3 {-0.02/7 0.4} f8 {+0.31/6 1.6} 15.
Gd5 {-0.02/8 0.6} Uf9 {+0.22/4 0.1} 16. Ug5 {-0.07/7 0.5} Lkh11
{+0.25/4 0.1} 17. Kg3 {-0.02/7 0.4} Gf10 {+0.18/4 0.3} 18. Cf3
{-0.06/7 0.4} Ci11 {+0.11/4 0.2} 19. Ue6 {-0.05/7 0.5} Uh6 {+0.01/4 0.3}
20. Ug5 {-0.05/7 0.4} Lg8 {+0.18/5 2.3} 21. i5 {-0.07/7 0.4} Lxg5
{+0.23/6 0.4} 22. ixh6 {-0.12/9 0.6} Ld6 {-0.02/6 0.2} 23. Af2
{-0.07/9 0.4} Gf9 {+0.12/5 0.9} 24. e5 {-0.10/8 0.5} Lc9 {-0.17/5 0.1} 25.
g5 {-0.07/7 0.4} g8 {-0.18/4 0.2} 26. Gi5 {-0.06/8 0.6} Gd7 {-0.03/4 0.2}
27. Cg4 {+0.00/7 0.6} Cg9 {-0.13/4 0.1} 28. Cxg9 {+0.01/8 0.3} Gxg9
{-0.36/5 0.1} 29. Cxb9 {-0.06/7 0.5} Lxh5 {-0.46/4 0.3} 30. Cg4
{-0.10/6 0.3} Lh8 {-0.24/5 0.2} 31. Gl7 {-0.15/7 0.5} Lf10 {-0.22/5 0.3}
32. Lh2 {-0.13/7 0.7} k8 {-0.01/4 0.5} 33. Gi5 {-0.25/7 0.6} Lk7
{+0.30/4 0.2} 34. Lk1 {-0.37/7 0.7} Gxh6 {+0.35/5 0.1} 35. gxh6
{-0.30/8 0.5} Lxh6+ {+0.22/5 0.8} 36. Kf3 {-0.40/8 0.8} Lfe7 {+0.14/5 0.6}
37. Ke3 {-0.51/8 0.7} Cg10 {-0.16/4 0.4} 38. Lh2 {-0.37/7 0.4} Ce8
{-0.03/3 0.1} 39. Rd1 {-0.37/7 0.6} Lk7 {+0.04/4 0.3} 40. Lk1 {-0.47/7 1.1}
Gj7 {+0.05/3 0.2} 41. l5 {-0.38/6 0.4} Leh7 {+0.15/4 1.5} 42. Kf3
{-0.46/7 0.5} Li4+ {+0.24/5 0.4} 43. Ke4 {-0.40/6 0.5} Li7 {+0.25/5 0.5}
44. Kf3 {-0.41/6 0.3} Lixj4 {+0.36/4 1.1} 45. Lxj4 {-0.31/8 0.3} Lxj4
{-0.17/7 0.6} 46. Ai3 {-0.38/7 0.5} Lxg4 {-0.27/6 0.2} 47. Axg4
{-0.27/7 0.4} Ag11 {-0.35/5 0.2} 48. Rh1 {-0.20/7 0.4} Rh12 {-0.35/5 0.2}
49. Rh6 {-0.21/7 0.5} Rb12 {-0.11/4 0.2} 50. Rl6 {-0.18/7 0.3} Rl12
{-0.11/4 0.2} 51. Gxk8 {+0.58/8 0.4} lxk8 {-1.05/5 0.4} 52. Rxl12+
{+0.53/8 0.3} Axl12 {-1.15/7 0.5} 53. Axh9+ {+0.66/8 0.6} Ag11
{-1.12/6 0.2} 54. Axg8 {+0.53/7 0.3} Ah4+ {-0.95/6 0.2} 55. Axh4+
{+0.62/8 0.6} Gxh4 {-0.94/7 0.4} 56. b5 {+0.56/9 0.6} Cj3 {-0.56/6 0.2} 57.
Lb4 {-0.25/8 0.3} Cxk4 {-0.18/6 0.4} 58. Rg1+ {-0.31/8 0.6} Kf11
{-0.25/5 0.4} 59. Le4 {-0.28/8 0.6} Rh12 {+0.35/6 0.3} 60. Rg9
{-0.23/8 0.3} Cxl5 {+0.58/6 0.5} 61. Rxe9 {+0.13/8 0.4} Ch1+ {+0.47/6 0.2}
62. Ke3 {+0.13/9 0.5} Cxe4 {+0.16/7 0.2} 63. Kxe4 {+0.13/8 0.3} Rd12
{-0.94/7 0.2} 64. Rxi9 {+1.38/8 0.6} f7 {-1.16/8 0.5} 65. Gg7 {+1.40/7 0.6}
Kf10 {-0.98/6 0.2} 66. Gxd9 {+1.56/9 0.6} Ra12 {-2.21/7 0.4}
{Xboard: Forfeit due to invalid move: i9g11 (i9g; via `0, `0) res=24} 0-1

and the relevant position is this one:
r11/12/5k6/p2G4C3/3p5pp1/5p6/12/1P2P7/P1PPKP1g4/12/12/12 w - 1 67

Postduif wants to play Cg11+ (i9g11) which as far as I can see is a legal move. The debug log is not very helpful:

Code: Select all

62301 <first &#58; # Position 'r11/12/5k6/p2G4C3/3p5pp1/5p6/12/1P2P7/P1PPKP1g4/12/12/12 w - 1 67'
62301 <first &#58;   2    52      0        91    67. Cxj8  Ra10  
 59112112112112112112112112112112112
112112112112112112112112112112112112
112112112112112111112112112112112112
 56112112 24112112112112  3112112112
112112112 56112112112112112 56 56112
112112112112112 56112112112112112112
112112112112112112112112112112112112
112  0112112  0112112112112112112112
  0112  0  0 55  0112 80112112112112
112112112112112112112112112112112112
112112112112112112112112112112112112
112112112112112112112112112112112112
Impossible move a1j1, type = 25
62302 <first &#58;   3    60      0       448    67. Cxj8  Ra10  68. Cf12  
 59112112112112112112112112112112112
112112112112112112112112112112112112
112112112112112111112112112112112112
 56112112 24112112112112  3112112112
112112112 56112112112112112 56 56112
112112112112112 56112112112112112112
112112112112112112112112112112112112
112  0112112  0112112112112112112112
  0112  0  0 55  0112 80112112112112
112112112112112112112112112112112112
112112112112112112112112112112112112
112112112112112112112112112112112112
Impossible move a1j1, type = 25
62302 <first &#58;   4    53      0      3789    67. Cg11  Ke10  68. Gf6   Ra10  69. Cxd8  
 59112112112112112112112112112112112
112112112112112112112112112112112112
112112112112112111112112112112112112
 56112112 24112112112112  3112112112
112112112 56112112112112112 56 56112
112112112112112 56112112112112112112
112112112112112112112112112112112112
112  0112112  0112112112112112112112
  0112  0  0 55  0112 80112112112112
112112112112112112112112112112112112
112112112112112112112112112112112112
112112112112112112112112112112112112
Impossible move a1g1, type = 25
62303 <first &#58;   5    52      0     12503    67. Cg11  Ke10  68. Gg7   Kf9   69. Cxd8  Rg12  70. Gd9   
 59112112112112112112112112112112112
112112112112112112112112112112112112
112112112112112111112112112112112112
 56112112 24112112112112  3112112112
112112112 56112112112112112 56 56112
112112112112112 56112112112112112112
112112112112112112112112112112112112
112  0112112  0112112112112112112112
  0112  0  0 55  0112 80112112112112
112112112112112112112112112112112112
112112112112112112112112112112112112
112112112112112112112112112112112112
Impossible move a1g1, type = 25
62304 <first &#58;   6    45      1     37808    67. Cxj8  Rg12  68. Cg5   Ke9   69. Cxh4  Kxd9  
 59112112112112112112112112112112112
112112112112112112112112112112112112
112112112112112111112112112112112112
 56112112 24112112112112  3112112112
112112112 56112112112112112 56 56112
112112112112112 56112112112112112112
112112112112112112112112112112112112
112  0112112  0112112112112112112112
  0112  0  0 55  0112 80112112112112
112112112112112112112112112112112112
112112112112112112112112112112112112
112112112112112112112112112112112112
Impossible move a1j1, type = 25
62304 <first &#58;   7    53      3    103398    67. Cxj8  Rg12  68. Cg5   Ke9   69. Cxh4  Kxd9  70. Cf6   
 59112112112112112112112112112112112
112112112112112112112112112112112112
112112112112112111112112112112112112
 56112112 24112112112112  3112112112
112112112 56112112112112112 56 56112
112112112112112 56112112112112112112
112112112112112112112112112112112112
112  0112112  0112112112112112112112
  0112  0  0 55  0112 80112112112112
112112112112112112112112112112112112
112112112112112112112112112112112112
112112112112112112112112112112112112
Impossible move a1j1, type = 25
62315 <first &#58;   8    46     11    351214    67. Cxj8  Rg12  68. Cg5   Ke9   69. Gb12  Gf1   70. Ch6   Ke8   71. c5    
 59112112112112112112112112112112112
112112112112112112112112112112112112
112112112112112111112112112112112112
 56112112 24112112112112  3112112112
112112112 56112112112112112 56 56112
112112112112112 56112112112112112112
112112112112112112112112112112112112
112  0112112  0112112112112112112112
  0112  0  0 55  0112 80112112112112
112112112112112112112112112112112112
112112112112112112112112112112112112
112112112112112112112112112112112112
Impossible move a1j1?, type = 25
62477 <first &#58;   9    45     27    924862    67. Cg11  Kf9   68. Cxj8  Rc12  69. c5    Rc9   70. Gg11  Rc7   71. b6    Re7   
 59112112112112112112112112112112112
112112112112112112112112112112112112
112112112112112111112112112112112112
 56112112 24112112112112  3112112112
112112112 56112112112112112 56 56112
112112112112112 56112112112112112112
112112112112112112112112112112112112
112  0112112  0112112112112112112112
  0112  0  0 55  0112 80112112112112
112112112112112112112112112112112112
112112112112112112112112112112112112
112112112112112112112112112112112112
Impossible move a1g1?, type = 25
62777 <first &#58;  10    45     57   1987582    67. Cg11  Kg10  68. Cxd8  Gf1   69. Cb10  Ri12  70. a5    Ri9   71. Gf6   a8    72. Cd12  
 59112112112112112112112112112112112
112112112112112112112112112112112112
112112112112112111112112112112112112
 56112112 24112112112112  3112112112
112112112 56112112112112112 56 56112
112112112112112 56112112112112112112
112112112112112112112112112112112112
112  0112112  0112112112112112112112
  0112  0  0 55  0112 80112112112112
112112112112112112112112112112112112
112112112112112112112112112112112112
112112112112112112112112112112112112
Impossible move a1g1?, type = 25
62777 <first &#58; # Nodes&#58; 1987582 &#40;3.48e+06 NPS&#41; Cut-offs&#58; 291235 Cut1&#58; 243698 &#40;83.68%) Cut<4&#58; 270396 &#40;92.84%), 99325 in hash &#40;0.00% cut&#41;
62777 <first &#58; # DQ&#58; -7
62777 <first &#58; move i9g11
GameEnds&#40;27, Xboard&#58; Forfeit due to invalid move&#58; i9g11 &#40;i9g; via `0, `0&#41; res=24, 4&#41;
GE&#40;27, Xboard&#58; Forfeit due to invalid move&#58; i9g11 &#40;i9g; via `0, `0&#41; res=24, 4&#41; bare king k=8 color=56

Now, I can't actually browse the full game history through XBoard either, because it claims "Illegal move: 17. Kg3". I guess this is just the PGN parser being unaware of the initial king move.

[hgm]

For me it also refuses 17. Kg3, when I paste the PGN. For the part of the game that it did load, it seems to think the double-steps are illegal for the white King already from the initial position. The black King has them, though, so it must have the correct piece definition for King. It must be a problem with virginity on loading the FEN in the PGN FEN tag. Not sure why that would be different for a FEN received in the setup command (or what PostDuif send it for castling rights; Fairy-Max still has a hard-coded KQkq in the setup FEN.

When I load the position you give, there is no complaint against the i9g11 move.

In any case it is clear there is an XBoard problem.

[hgm]

OK, I solved the spurious Illegal-move complaint on 17. Kg3. In the parent variant Shatranj there is no castling, so the fen reader does not attempt to parse a castling field. But it also did not clear the virginity flags of the back-rank pieces (which are used by the Betza generator) as default action, so they remained unitialized.

I guess we have to rethink FEN castling rights for royals with initial moves other than castling, or in engine-defined variants in general. XBoard should keep track of any piece definitions that involve initial moves, and store as well as parse their virginity in the castling field. The logical way to do it is as in Seirawan Chess, except that K and Q as short-hand for virginity of King and a Rook seems very unnatural if there is no actual castling. So in variants without castling we should just print the file IDs of the virgin pieces that have an 'i' in their Betza descriptor. That means that for Grande Acedrex the castling field of the initial position should contain "Gg" to indicate King virginity.

Now that I can load the game, it seems that XBoard at least was right about i9g11 being an illegal move: the FEN you gave is not the final position of that game. There is a Rook on i9, and not a Bishop. That Rook got there by 64. Rxi9.

[Evert]

OK, I solved the spurious Illegal-move complaint on 17. Kg3. In the parent variant Shatranj there is no castling, so the fen reader does not attempt to parse a castling field. But it also did not clear the virginity flags of the back-rank pieces (which are used by the Betza generator) as default action, so they remained unitialized.

I guess we have to rethink FEN castling rights for royals with initial moves other than castling, or in engine-defined variants in general. XBoard should keep track of any piece definitions that involve initial moves, and store as well as parse their virginity in the castling field. The logical way to do it is as in Seirawan Chess, except that K and Q as short-hand for virginity of King and a Rook seems very unnatural if there is no actual castling. So in variants without castling we should just print the file IDs of the virgin pieces that have an 'i' in their Betza descriptor. That means that for Grande Acedrex the castling field of the initial position should contain "Gg" to indicate King virginity.

Hmm... I think I switched to variant "fairy" instead of "shatranj", which didn't make a difference for the castling, apparently.
I can certainly switch to using "Gg" for castling rights. In fact, I could just change the code I have now

Code: Select all

   while (*s && !isspace(*s)) {
      if (*s == 'K') board->piece_list[PIECE_LIST_ROYAL_START].virgin = true;
      if (*s == 'k') board->piece_list[PIECE_LIST_ROYAL_START+MAX_PIECES_PER_SIDE].virgin = true;
      s++;
   }

to

Code: Select all

   while (*s && !isspace(*s)) {
      if (isupper(*s)) board->piece_list[PIECE_LIST_ROYAL_START].virgin = true;
      if (islower(*s)) board->piece_list[PIECE_LIST_ROYAL_START+MAX_PIECES_PER_SIDE].virgin = true;
      s++;
   }

and call it a day...

Now that I can load the game, it seems that XBoard at least was right about i9g11 being an illegal move: the FEN you gave is not the final position of that game. There is a Rook on i9, and not a Bishop. That Rook got there by 64. Rxi9.

Ah, that does make sense then.
I took the FEN from Postduif's output (it prints the FEN for the current position at the start of the search, for convenience), but it did indeed have a rather interesting bug where pieces could change identity.

I think it was caused by my clever re-use of indices in the piece-list for promoted pieces: this would override the piece-ID stored at that entry, which was not restored to what it was originally when the move was retracted, so if a piece was captured during the search and a pawn promoted to a piece in the same index category, the piece would change into the promoted piece. That could have been a head-ache to debug if it hadn't occurred to me that this is what was happening (it's one of those bugs that don't reproduce consistently when you re-search a position).

Postduif now seems to be running quite smoothly. It still has no evaluation to speak of though: centralise everything and come the end game, push everything as far forward as possible. Seems to do ok against Fairy-Max now though...

[hgm]

At least Fairy-Max now uses the initial two-step move of the King spontaneously, to move it to the side. I am still thinking about flipping the centralization weight (from 1 to -1) of King initially, and only restore it to the center-seeking +1 when the gamePhase variable indicates the end-game has started. That might make the King march further towards the corner.

Fairy-Max' centralization table contains the square of the distance to the board center. On 12x12 boards this is 5.5^2 = 30 cP lower in the corner than the center, for each dimension. Of course the King starts already on the board edge, but there is still 30 cP to earn by moving to the a-file if it was made edge-seeking. One file away from the edge the bonus would be 4.5^2 = 20 cP, though, and two files away only 12 cP. So the bonus for successive steps would increase (once the initial move has brought it on e-file) as 6, 8, 10; 8 cP on average per move. But the King-move penalty is 20cP per move. So I should perhaps make the initial centralization weight even -2, and lower the penalty to 15cP per move. The effect of this on normal Chess should be pretty small, as there are not many prositional advantages that would compete even with 15cP.

I adapted the passing-through-check test, and stride-4 castlings now completely work in Fairy-Max. So it can do Janus Chess now, where the King castles from e-file to i-file. For Wildebeest Chess it still suffers from not allowing e.p. capture on the first skipped square on a triple push (I suspect Mexican Chess should have this too), not having a double-push on 3nd rank (no ideas yet how to implement that, neither in the engine as in XBetza), and not having stride-1 castling. Perhaps I should just drop the idea of doing that.

[hgm]

I pushed an XBoard commit now that detects if variants have a King with initial moves but no castling, and in that case just dumps the file ID of all virgin back-rank pieces with initial moves (or a '-' if there are none) in the castling field. This works for Grande Acedrex and Ouk, but it would fail to detect pieces that have initial moves defined on them when the King has not, or castles normally. But for now it should do.

It might be a bit flaky, because the piece commands are sent after the setup command, so at the time the setup FEN is interpreted it is not known whether such a virginity field is to be expected. But the nature of a setup FEN is such that all pieces can be assumed virgin, which is the default in absence of a virginity field, so I hope this is no problem in practice. For Grande Acedrex it seemed to work: I could copy the FEN of the initial position to gedit, and it contains Gg. When I replace this for - and paste it back, the Kings can no longer do the double move.

[Evert]

Here's another oddity:

Fairy-Max ("second") claims a draw by repetition, but is too soon:

Code: Select all

73199 <second&#58; 10      0       13     116634 b1b2
73399 <second&#58; # times @ 1066009202&#58; real=339 cpu=340
73399 <second&#58; # promo = 0 (`) GT = 0
73399 <second&#58; move b1b2
73400 >first &#58; time 240
73400 >first &#58; otim 575
book hit = &#40;NULL&#41;
73400 >first &#58; b1b2
73468 <second&#58; 1/2-1/2 &#123;Draw by repetition&#125;
GameEnds&#40;28, Draw by repetition, 6&#41;
GE&#40;26, False draw claim&#58; 'Draw by repetition', 6&#41; bare king k=10 color=0
write FEN 50-move&#58; 0 154 0

Now, the move has already been sent to Postduif, which starts thinking. XBoard sends it the result and a "ping 4":

Code: Select all

73470 >first : result 1-0 {False draw claim: 'Draw by repetition'}
Interrupting second
73470 >second: result 1-0 {False draw claim: 'Draw by repetition'}
73470 >first : force
73470 >first : ping 4

Postduif is still processing the move:

Code: Select all

73470 <first &#58; # Position '12/12/6k5/12/2ppLGG1pR2/7g3p/12/7P3P/P4l2P1P1/12/1r8K1/12 w - 11 78'
73470 <first &#58;   2   355      0       223    78. Kl1   Re2   
73470 <first &#58;   3   348      0       606    78. Kj3   Kf9   79. Lf11  
73470 <first &#58;   4   338      0      2244    78. Kj3   Kf9   79. Lf5   i7    
73470 <first &#58;   5   271      0      3494    78. Kj3?
73470 <first &#58;   5   347      0      8107    78. Kj3   Kf9   79. Lf5   Rb3   80. Kk2   i7    
73470 <first &#58;   6   295      0     10822    78. Kj3?
73470 <first &#58;   6   243      1     18216    78. Kj3   Rb3   79. Kk2   Rb2   80. Kj1   Lxi4  81. Kk1   i7    
73470 <first &#58;   7   190      2     31276    78. Kj3?
73470 <first &#58;   7   247      4     80331    78. Kj3   Rb3   79. Kj2   Rb2   80. Kj1   Lxi4  81. Kk1   Kf9   82. Lf11  

Xboard sends it the commands to ready a new game:

Code: Select all

73481 >first : memory 2052
73481 >first : new
random
73481 >first : variant grande-acedrex
73481 >first : level 40 0:20 0
73481 >first : post
73481 >first : hard
73481 >first : easy
73481 >first : ping 5
Impossible move b1b2, type = 0
73483 >first : force

Postduif is still thinking:

Code: Select all

73699 <first &#58;   8   237     29    555326    78. Kj3   Rb3   79. Kj2   Rb2   80. Kj1   Lxi4  81. Kk1   Kf9   82. Lf11  i7    
74010 <first &#58;   9   236     61   1182333    78. Kj3   Rb3   79. Kj2   Rb2   80. Kj1   Lxi4  81. Kk1   Kf9   82. Lf11  Lf5   83. Rj9   Ke10  
74011 <first &#58; # Position '12/12/6k5/12/2ppLGG1pR2/7g3p/12/7P3P/P4l2P1P1/12/1r8K1/12 w - 11 78'
74011 <first &#58; # Nodes&#58; 1182333 &#40;1.94e+06 NPS&#41; Cut-offs&#58; 145495 Cut1&#58; 124540 &#40;85.60%) Cut<4&#58; 140257 &#40;96.40%), 58397 in hash &#40;20.80% cut&#41;
74011 <first &#58; # DQ&#58; -9
74011 <first &#58; move k2j3

Now XBoard responds to the move by sending an undo:

Code: Select all

74011 >first : undo
74011 <first &#58; pong 4

So now Postduif has processed the end of the last game and is ready to start a new game (never mind that I apparently forgot to implement "memory"):

Code: Select all

74011 <first &#58; Error &#40;unknown command&#41;&#58; memory 2052
74016 <first &#58; setup &#40;P.CR.............A..U...G..LKp.cr.............a..u...g..lk&#41; 12x12+0_fairy rlugcakcgulr/12/12/pppppppppppp/12/12/12/12/PPPPPPPPPPPP/12/12/RLUGCAKCGULR w Kk 0 1
recognized 'fairy' (-1&#41; as variant grande-acedrex
recognized 'fairy' (-1&#41; as variant grande-acedrex
shuffleOpenings = 0
FEN castling rights&#58; 11 114 6 11 114 6
74021 <first &#58; piece P& fmWfcF
74021 <first &#58; piece K& KimDimA
74021 <first &#58; piece R& R
74021 <first &#58; piece C& B
74021 <first &#58; piece N& N
74021 <first &#58; piece F& F
74021 <first &#58; piece W& W
74021 <first &#58; piece M& K
74021 <first &#58; piece E& A
74021 <first &#58; piece D& D
74021 <first &#58; piece G& Z
74021 <first &#58; piece S& C
74021 <first &#58; piece L& HC
74021 <first &#58; piece A& FyafsF
74021 <first &#58; piece U& NmpafsyafW
74021 <first &#58; piece V& yafF
74021 <first &#58; piece J& afsafyafF
74023 <first &#58; pong 5

So now it's ready to start the new game. Problem: XBoard has already sent it an undo command. This causes it to take back the last move, which is non-existent. However, this still causes it to flip the side to move:

Code: Select all

84214 <second&#58;  5     34       74     381598 j1g3 c12f10 k1h2 b12e11 c1f3
84357 <second&#58; # times @ 1066020160&#58; real=884 cpu=880
84357 <second&#58; # promo = 0 (`) GT = 0
84357 <second&#58; move j1g3
84358 >first &#58; time 2000
84358 >first &#58; otim 1911
book hit = &#40;NULL&#41;
84358 >first &#58; j1g3
84358 >first &#58; go
84457 <first &#58; Invalid move&#58; j1g3
84457 <first &#58; # Position 'rlugcakcgulr/12/12/pppppppppppp/12/12/12/12/PPPPPPPPPPPP/12/12/RLUGCAKCGULR b kK 0 1'

Now, arguably Postduif should do nothing if there is no move at all to "undo", but I don't think there is any reason for XBoard to have sent that "undo" in the first place. It certainly shouldn't send it after "ping 5" has been sent. Perhaps it should actually wait until it has received "pong 4" before setting up the new game, to make sure the engine and GUI are synchronised?

On a different note, from what I've seen in the few games I've watched Unicorns are really aweful for search explosions in QS (I've seen F-Max lose a game because it couldn't finish the depth=2 search with unicorns from both sides behind enemy lines). Postduif is really aweful about developing its pieces: it centralises a handful and then the rest just stand there on the back rank while it shuffles the pieces it already developed. F-Max does this a whole lot better; does it have some sort of development term in its evaluation?

[hgm]

Most shocking is of course that Fairy-Max claims a draw too soon. The draw-claim code is not really in the engine, but in the interface. I added it because it was a requirement to have micro-Max tested in WBEC (which required it because WinBoard could not adjudicate such things at the time). So I just had the interface store all boards of the game history, to compare against the current position. Probably this board storage overflows because of the larger board (or ignores part of it).

As to the 'undo', this is the same bug as Steven Edwards is plagued by in ICS play. XBoard has some strange code at the top of HandleMachineMove(), which decides when to undo out-of-turn moves. I don't understand what exactly it is supposed to do, and why it is so complex. I suppose there is a race condition when you send a 'force' command to a thinking engine. This is supposed to abort the search without move, but a move could already be on the way. The engine would then be out of phase with the GUI, and you have to send the undo. In engines that support ping this should never be a problem if ping is used properly, but perhaps it isn't. So it tries to detect cases for sending undo even when there is a ping unbalance, and apparently sometimes it overdoes that. Anyway, this is at the top of my to-do list now.

As to the Unicorns: it doesn't seem these are more efficient at plunder raids as Queens would be. And MVV/LVA should effectively stop that. It could be that in Gran Acedrex it is much more likely that pieces are unprotected, but any powerful piece would suffer from that. Could it be that it is not so much a QS problem, as a check extension? I don't know if these bent sliders can somehow set up a mutual perpetual check. Fairy-Max had these search explosions when it played with Nightriders, which in combination with FIDE sliders can also set up mutual perpetual checks. Now that Fairy-Max can detect repetitions in search it should be somewhat less sensitive to that, but it is still conceivable that a mutual King chase could go on very long on a large board.

Do you still have the position where this occurred?

[Evert]

Most shocking is of course that Fairy-Max claims a draw too soon. The draw-claim code is not really in the engine, but in the interface. I added it because it was a requirement to have micro-Max tested in WBEC (which required it because WinBoard could not adjudicate such things at the time). So I just had the interface store all boards of the game history, to compare against the current position. Probably this board storage overflows because of the larger board (or ignores part of it).

As to the 'undo', this is the same bug as Steven Edwards is plagued by in ICS play. XBoard has some strange code at the top of HandleMachineMove(), which decides when to undo out-of-turn moves. I don't understand what exactly it is supposed to do, and why it is so complex. I suppose there is a race condition when you send a 'force' command to a thinking engine. This is supposed to abort the search without move, but a move could already be on the way. The engine would then be out of phase with the GUI, and you have to send the undo. In engines that support ping this should never be a problem if ping is used properly, but perhaps it isn't. So it tries to detect cases for sending undo even when there is a ping unbalance, and apparently sometimes it overdoes that. Anyway, this is at the top of my to-do list now.

I can imagine it's more difficult to resolve than it sounds, especially if you don't know why the code is as complex as it is. Perhaps it's a shoddy implementation, but perhaps it's really needed.

I guess what I would do in that case is work out (on paper) how it should work, shelf the old code and write new code from scratch. Then of course it needs to be tested thoroughly...

As to the Unicorns: it doesn't seem these are more efficient at plunder raids as Queens would be. And MVV/LVA should effectively stop that. It could be that in Gran Acedrex it is much more likely that pieces are unprotected, but any powerful piece would suffer from that. Could it be that it is not so much a QS problem, as a check extension? I don't know if these bent sliders can somehow set up a mutual perpetual check. Fairy-Max had these search explosions when it played with Nightriders, which in combination with FIDE sliders can also set up mutual perpetual checks. Now that Fairy-Max can detect repetitions in search it should be somewhat less sensitive to that, but it is still conceivable that a mutual King chase could go on very long on a large board.

It seems that the position in question did have a lot of opportunities for checks, and it involved both Unicorns and Gryphons on both sides, so it could well be a combination.

My impression that the Unicorn is a deadly piece for this is its ability to jump. It leaps in, grabs pieces, leaps out and then back in on the other side of the board. Repeat. The Gryphon is less agile (also because it can be trapped more easily). Of course if you can get behind the line of enemy pawns, the king is almost guaranteed to be exposed.

Do you still have the position where this occurred?

I actually have the game:

Code: Select all

[Event "Computer Chess Game"]
[Site "vivaine.local"]
[Date "2016.01.14"]
[Round "1"]
[White "Postduif 0.14"]
[Black "Fairy-Max 4.8V"]
[Result "1-0"]
[TimeControl "40/20"]
[Variant "grande-acedrex"]
[VariantMen "P:fmWfcF;C:B;R:R;A:FyafsF;U:NmpafsyafW;G:Z;L:HC;K:KimDimA"]
[FEN "rlugcakcgulr/12/12/pppppppppppp/12/12/12/12/PPPPPPPPPPPP/12/12/RLUGCAKCGULR w Kk - 0 1"]
[SetUp "1"]

{--------------
r l u g c a k c g u l r
. . . . . . . . . . . .
. . . . . . . . . . . .
p p p p p p p p p p p p
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
P P P P P P P P P P P P
. . . . . . . . . . . .
. . . . . . . . . . . .
R L U G C A K C G U L R
white to play
--------------}
1. Uf3 {+0.17/8} Gg10 {+0.40/5 1.0} 2. Ug5 {+0.31/8 0.5} Uf10 {+0.29/5 1.2}
3. Ui3 {+0.47/7 0.4} Ac11 {-0.20/4 0.2} 4. Uif7 {+0.51/7 0.3} Ug8
{-0.11/5 0.2} 5. Gf3 {+0.47/6 0.3} Ui10 {+0.01/4 0.2} 6. Gd6 {+0.78/6 0.5}
Ugxd4 {-0.85/5 0.5} 7. Gxf9 {+0.30/9 0.5} Uxf1 {+0.03/5 0.6} 8. Kxf1
{+0.56/9 0.5} Ad10 {-0.34/5 0.2} 9. Gxh12 {+0.87/9 0.4} Lxh12 {-0.50/5 0.5}
10. Uxj9 {+0.83/9 0.5} g8 {-0.78/5 1.0} 11. Ufh10+ {+0.82/8 0.5} Ke10
{-0.73/5 1.4} 12. e5 {+0.42/8 0.4} Lbe11 {-0.30/6 1.0} 13. Uc6
{+0.22/8 0.3} Lg9 {-0.53/6 0.4} 14. Ug5 {+0.18/9 0.6} Lf8 {-0.51/5 0.2} 15.
Ue4 {+0.18/7 0.6} Gi7 {-0.90/4 0.3} 16. Cf3 {+0.08/8 0.4} Lg6 {-0.75/4 0.2}
17. Ce2 {-0.06/7 0.6} Cg10 {-0.77/4 0.4} 18. Ua5 {-0.31/7 0.4} Gg9
{-0.89/4 0.4} 19. h5 {-0.35/6 0.4} Gd7 {-1.14/4 0.2} 20. Ub7 {-0.50/8 0.6}
Gg5 {-1.09/4 0.5} 21. Ui1 {+0.28/7 0.3} Lj7 {-1.23/4 0.4} 22. fxg5
{-0.45/7 0.8} Lxe5 {-1.09/4 0.2} 23. Ra3 {-0.35/6 0.3} Lxi4 {-1.14/3 0.2}
24. Uh3 {-1.31/7 0.6} Rlf12+ {-0.54/3 0.2} 25. Kg1 {-0.85/8 0.4} Lj1+
{-0.20/4 0.2} 26. Kh2 {-1.27/9 0.6} Le8 {-0.21/4 0.4} 27. Ug3 {-1.33/8 0.4}
Lxk4 {+0.36/6 0.3} 28. Lxk4 {-1.33/10 0.5} Gxk4+ {+0.45/6 2.0} 29. Ki2
{-1.27/9 0.3} Ud4 {+0.25/6 2.6} 30. Ra1 {-1.13/8 0.3} Uf7 {+0.25/5 2.3} 31.
Ue6 {-1.11/7 0.4} Ak11 {+0.35/4 0.3} 32. Kh1 {-1.60/8 0.7} Uxj4+
{+0.51/3 0.1} 33. Uxj4 {-0.68/10 0.7} Axj4 {-0.86/3 0.1} 34. Uxc9+
{-1.58/9 0.5} Kf9 {+0.88/3 0.1} 35. Rj1 {-1.15/9 0.4} Ak2 {+0.89/2 0.1} 36.
Ki2 {-1.13/8 0.5} Axl4 {+0.96/2 0.1} 37. Rf1+ {+9.47/10 0.5} Kg9
{+0.77/1 0.1} 38. Cj6+ {+9.61/9 0.9} Gi7 {-6.55/1 0.1} 39. Cxl4
{+11.83/9 0.7} Rxf1 {-6.55/1 0.1} 40. Cxf1 {+12.75/9 0.6} Rb12
{-9.51/1 0.1} 41. Ue10+ {+15.83/9 0.5} Kh10 {-12.29/7 0.2} 42. Uxb12
{+15.78/10 0.5} Gxg4 {-12.59/7 0.2} 43. Uxd9 {+15.77/9 0.5} Le5
{-12.25/6 0.5} 44. Uf6 {+14.55/9 0.4} Ld2 {-12.19/5 0.3} 45. Ra3
{+14.47/8 0.4} Lxa3 {-12.13/6 0.3} 46. Gxa3 {+14.71/8 0.5} i8
{-12.74/6 0.7} 47. Ck3 {+16.86/8 0.5} Gd2 {-13.02/5 0.3} 48. Cxe9
{+15.55/8 0.5} Cxa4 {-13.02/6 0.3} 49. Ch3 {+17.03/7 0.5} b8 {-12.72/5 0.3}
50. Ue4 {+16.20/7 0.5} Cc2 {-13.37/8 0.5} 51. Uxd2 {+16.98/9 0.5} Cxb1
{-14.29/8 1.0} 52. Uxb1 {+17.03/8 0.7} Kg9 {-14.44/8 0.3} 53. Uk11
{+17.27/8 0.3} l8 {-14.47/7 0.2} 54. Cd7 {+17.92/8 0.5} b7 {-14.72/7 0.2}
55. Ui10+ {+18.31/9 0.4} Kh10 {-15.71/8 0.2} 56. Uxk9 {+18.76/9 0.6} Ki9
{-16.36/8 1.1} 57. Cg7+ {+19.10/7 0.5} Kj9 {-15.85/7 0.3} 58. Ul7
{+19.16/8 0.4} a8 {-15.66/7 0.2} 59. Ug11+ {+19.73/7 0.3} Kk9
{-16.54/6 0.2} 60. Uxh9 {+19.87/8 0.8} l7 {-16.53/7 0.3} 61. Uf12
{+20.51/8 0.4} Kk10 {-17.71/7 0.2} 62. Uxi8 {+20.91/8 0.3} a7
{-18.11/7 0.5} 63. Uj10 {+21.00/7 0.3} l6 {-18.41/7 0.4} 64. Uxg8
{+21.72/7 0.3} a6 {-18.60/7 0.5} 65. Cc8 {+22.52/7 1.0} b6 {-18.80/7 0.2}
66. Cxa6 {+22.70/7 0.6} l5 {-19.66/7 0.3} 67. Cf11 {+24.12/8 0.9} l4
{-20.46/7 0.6} 68. Uxl4 {+24.25/7 0.5} Kj11 {-20.88/7 0.2} 69. Uh7
{+24.65/8 0.4} Ki10 {-20.81/7 0.3} 70. Ce9 {+24.78/7 0.7} Kj9
{-21.22/7 0.3} 71. Cxb6 {+24.92/7 0.3} Kk8 {-21.06/7 0.5} 72. Ch12
{+31.22/8 0.6} Kj9 {-21.06/7 0.3} 73. Gd5 {+25.31/7 0.3} Kk8 {-21.35/7 0.2}
74. Gg7 {+25.35/7 0.4} Kl7 {-21.51/7 0.3} 75. Cg10 {+31.82/7 0.6} Kk8
{-21.44/7 0.2} 76. g6 {+25.53/7 0.6} Kk7 {-21.68/7 0.3} 77. Gi4+
{+25.65/7 0.6} Kk8 {-21.78/7 0.3} 78. h6 {+25.65/7 0.6} Kj9 {-22.23/7 0.3}
79. Gg7+ {+25.68/7 0.6} Kk8 {-22.22/8 0.8} 80. Kh3 {+32.08/7 0.7} Kk7
{-22.59/8 1.1} 81. Kg4 {+32.25/7 0.5} Kk8 {-21.93/7 0.3} 82. c5
{+32.26/7 0.5} Kk7 {-22.42/7 0.2} 83. Ug9 {+32.26/7 0.5} Kj6 {-21.67/7 0.5}
84. Uj7 {+32.20/7 0.5} Kk7 {-21.48/7 0.4} 85. Cg11+ {+32.32/7 0.5} Kj6
{-22.05/8 0.8} 86. c6 {+32.40/8 0.5} Kk6 {-21.87/8 1.4} 87. Cf10
{+32.37/7 0.5} Kk7 {-21.14/7 0.2} 88. Ug11 {+25.95/7 0.3} Kj8
{-22.37/7 0.2} 89. Ci7+ {+319.91/7 0.2} Kk7 {-22.33/8 0.7} 90. Uj9+
{+319.93/7 0.5} Kk8 {-79.97/10 0.2} 91. Uh10+ {+319.95/5 0.1} Kk7
{-79.98/20 0.2} 92. Cj7 {+319.97/3 0.1} Kl8 {-79.99/28 0.1} 93. Gi10#
{+319.99/2 0.1}
{Xboard adjudication: Checkmate} 1-0

Problems start just after move 30, where F-Max' search depth starts to drop steadily until it captures a poisoned pawn on move 36. It looks like it only completes one iteration on the next ply (37... Kg9), but I think all the alternatives are actually worse.