Grande Acedrex

[Evert]

The bent sliders are indeed a pain, as well as the large number of oblique leaps. I don't think scanning away from the King could be competitive. (For Chess it surprisingly is not that bad, as the King is tucked away safely for most of the game, so that most rays away from it very quickly meet an obstruction.)

For Jazz and SjaakII that is indeed more or less what I do, but of course testing for attacks using bitboards is fast because for leapers you can test all possible locations in one test and for sliders you you don't need to scan along the entire ray (and you get at least 2 or 4 rays per check, depending on whether you do simple kinder-garten or full magic bitboards).

So yes, testing the pieces to see if they check seems the best method here. I don't know how you check that, but a 0x88-type test seems possible, where you very quickly see if a piece is on a square where it would deliver check on an extra board, and tabulate the direction you would have to scan from the King (if the piece was a slider) to scan the ray for blockers.

I'm not sure how to generalise the 0x88-test for 12x12 boards. Even then it's not a big help because of the oblique sliders.

Complication here is that for Griffon and Rhino checks you would not automatically bump into the checker during that ray scan. So you would have to tabulate in addition on what square a bent check would turn the corner.

Well, for each square along a ray direction there are only two squares (for both Griffon and Rhino) from which is it could attack the king, so that's perhaps not too bad...

The above is for a 'from scratch' check test, though. If you merely want to know if the latest move delivered check, you would only have to test the moved piece in the way described above, and test for traditional alignment of the from-square and the King. If the ray scan from King then reaches the from-square, you would have to continue that scan not only testing for Rooks or Bishops on that ray, but also for Griffons or Rhinos on the squares on both sides next to it. (This could probably be done better using piece-list info, but as it is rare that the King connects with the from-square, that does not matter anymore.)

True, that would be easier and I don't do that either at the moment. I'll inevitably add that at some point, but until I have a search (with check extension) or evasion generator it's not needed, I think.

If you want to test if the latest move put yourself in check you would have to do the above test on the from-square for non-King moves, but the 'from-scratch' test when you moved the King.

If you already were in check, and want to know if the move resolved it, you test King moves in the usual way, but other moves should be tested forlanding on the check ray, closer to the King as the checker. So presumably the in-check test would have given you the check ray (e.g. by step vector) and distance of the checker (or the corner where it moved on the ray), and you would test the king-toSqr distance and direction against that. Complication here is that capture of the checker could now be off-ray, so for Griffon and Rhino checks you would also have to test explicitly if the to-square coincides with the checker location, as it is no longer implied by the distance.

See, I know how to do all that using bitboards, but I have trouble seeing it with mailbox.
Perhaps the first order of business is to record the checking pieces and proceed from there (I don't currently do this: if I've found one checker I just return "in check" and don't bother looking for the others). A quick count suggested that you can have a discovered check by up to 3 checkers (or even 4 if you have two Gryphons but that will be very rare).

As for Fairy-Max:
It turns out that about half the variables are (signed char), which is quite fatal for storing square numbers above 127. So I guess that to make progress towards support of larger boards I will need to convert all those to another data type...

Ouch.

I actually cheat a little: I have a 15x18 mailbox board, so square numbers go up to 270, but on-board squares only go up to 225 so I store square numbers in an (unsigned) char in the piece-list(which is marginally but measurably faster than storing them in an int).

[hgm]

I'm not sure how to generalise the 0x88-test for 12x12 boards. Even then it's not a big help because of the oblique sliders.

Just use a 24x12 board. For the 0x88 attack test it is only important that there are enough unused files to make the square-number difference an unambiguous indicator of the board step, so that it can be used as index in a table lookup to find the type of move, basic step and distance. You don't care much about whether it is easy to see from the bit pattern if you stray off board; this is done more efficiently by just surrounding the board with a rim of boundary guards, even for 8x8 boards.

Well, for each square along a ray direction there are only two squares (for both Griffon and Rhino) from which is it could attack the king, so that's perhaps not too bad...

Well, along diagonals you would only have to check for Rhinos, along orthogonals only for Griffons. You would still have to check three squares instead of one, making this part of the ray scan 3 times as expensive. But the secret of course is that it would almost never have to be done, because most moves do not Q-align their from-square with the King, and the few that do would usually see the ray blocked already between King and from-square.

A faster alternative would be to go (in the cases where the ray-scan did reach the from-square) to go to the piece list, and test the applicable bent sliders there for being positioned for checking along that ray (through the 0x88 attack test, comparing the base step). Then scan to the next obstacle on the ray (to test for enemy Rook/Bishop), and when you find it compare its distance to that of the aligned bent slider. The speedup would probably be unmeasurable, though.

This reminds me that you can have double-checks here (and even triple checks) that can be evaded by interposition: two Rhinos and a Bishop checking along the same diagonal. Capturing the checker would not help then, but interposing on the diagonal close to the King would. The evasion generator would have to take that into account; usually I just generate King moves on double checks.

True, that would be easier and I don't do that either at the moment. I'll inevitably add that at some point, but until I have a search (with check extension) or evasion generator it's not needed, I think.

Perhaps the first order of business is to record the checking pieces and proceed from there (I don't currently do this: if I've found one checker I just return "in check" and don't bother looking for the others). A quick count suggested that you can have a discovered check by up to 3 checkers (or even 4 if you have two Gryphons but that will be very rare).

Normally I indeed test for both, because even if you already have established that the mover checks you, it would be of interest to the evasion generator if there is a double-check. The test itself is quite cheap, because usually the from-square does not even align. But it potentially saves you generating all moves but King moves (and testing them for being a valid evasion). If a check is found I record the checker, but if a second checker is found I invalidate that again in a way that makes it recognizable as a double check. In Chess for double checks the checkers are irrelevant. Not so here, though...

I actually cheat a little: I have a 15x18 mailbox board, so square numbers go up to 270, but on-board squares only go up to 225 so I store square numbers in an (unsigned) char in the piece-list(which is marginally but measurably faster than storing them in an int).

Amazing that there is a speed difference. Storing the move in the hash entry is usually another bottle-neck, though. The problem with 15x18 is that you cannot use the 0x88-style attack test; you would need at least 23x18 for that. You could use a translation table (I think TSCP does that) from 15x18 (unsigned char) square numbering to 24x12 (int) numbering, and then use the difference of the latter to index the alignment/step/distance tables. But I am pretty sure that would kill all spead advantage. An alternative would be to just ignore the problem, so that you now and then will detect false slider alignment (the ray crossing the edge), which the ray scan then will consider blocked anyway when it bumps into the board margin.

[Evert]

I'm not sure how to generalise the 0x88-test for 12x12 boards. Even then it's not a big help because of the oblique sliders.

Just use a 24x12 board. For the 0x88 attack test it is only important that there are enough unused files to make the square-number difference an unambiguous indicator of the board step, so that it can be used as index in a table lookup to find the type of move, basic step and distance. You don't care much about whether it is easy to see from the bit pattern if you stray off board; this is done more efficiently by just surrounding the board with a rim of boundary guards, even for 8x8 boards.

Hmm... unfortunately the squares of a 24x12 board don't fit in a char, so then I wouldn't be able to store moves using the mailbox coordinates.

This reminds me that you can have double-checks here (and even triple checks) that can be evaded by interposition: two Rhinos and a Bishop checking along the same diagonal. Capturing the checker would not help then, but interposing on the diagonal close to the King would. The evasion generator would have to take that into account; usually I just generate King moves on double checks.

Good point, I hadn't actually thought about the Rhino/Bishop combination (I had only thought about a discovered check by a Rhino or Giraffe that also exposes a Rook and two Gryphons).

I actually cheat a little: I have a 15x18 mailbox board, so square numbers go up to 270, but on-board squares only go up to 225 so I store square numbers in an (unsigned) char in the piece-list(which is marginally but measurably faster than storing them in an int).

Amazing that there is a speed difference. Storing the move in the hash entry is usually another bottle-neck, though.

I did say marginally - it's in the order of a percent or so in perft. That's insignificant, but I still want valid coordinates in the 0-255 range so I can encode the from and to squares together in a 16 bit integer.

The problem with 15x18 is that you cannot use the 0x88-style attack test; you would need at least 23x18 for that. You could use a translation table (I think TSCP does that) from 15x18 (unsigned char) square numbering to 24x12 (int) numbering, and then use the difference of the latter to index the alignment/step/distance tables. But I am pretty sure that would kill all spead advantage. An alternative would be to just ignore the problem, so that you now and then will detect false slider alignment (the ray crossing the edge), which the ray scan then will consider blocked anyway when it bumps into the board margin.

That sounds like it wouldn't be too bad, actually. I'll give that a go.

[hgm]

Fairy-Max now holds all square numbers as int, except in the hash, where it is unsigned char. It always had a 16xN board, and did not use the 0x88 attack test. But it did use the '128' bit ('S') of the to-square number to flag a move was valid and could be used as hash move, leaving only 7 bits for the actual square number. Now that it is all ints I can use the '256' bit for that. Except that that doesn't survive hashing.

So I switched to the following trick: if the S-bit of toSqr is set I store toSqr+1 in the hash, otherwise just 0 to flag the invalid hash move. When probing the hash it adds S-1 to the stored toSqr. When toSqr=0 that would just leave S-1, which does not have the S bit set and is considered invalid by the existing code. Otherwise it undoes the +1 used when storing, and adds the S-bit back. This should allow boards of up to 16 ranks. The width can be at most 16 minus the largest lateral leap (so 14 with nothing worse than Knights, 13 with the Grande Acedrex pieces).

[hgm]

Well, Fairy-Max plays on 12x12! (Bloody 2-digit I/O... XBoard's 'edit' command was also broken on boards with >10 ranks!)

Still enough problems with Grande Acedrex, though: Pawns start on 2nd rank, I still have to define the King's iAiD moves, and (worst of all) the promotion choice should be different for each rank (and that in an engine that does not know under-promotion...)

When I make the parent variant fairy, it has great difficulty winning KLK at 40/1min. At 40/5min it managed it. I still have the feeling that using the baring rule spoils part of the fun.

[d]8/4k3/2N5/3K4/8/8/8/8 w
Knight represents Lion

1. Ke5 Kd8 2. Lf7 Kd7 3. Kd5 Ke7 4. Lc7 Kd7 5. Ld4+ Ke8 6. Ke6 Kd8 7. Kd6 Ke8 8. Lc7 Kd8 9. Lf7 Ke8 10. Lc8 Kd8 11. Ld5#

[Evert]

Still enough problems with Grande Acedrex, though: Pawns start on 2nd rank, I still have to define the King's iAiD moves, and (worst of all) the promotion choice should be different for each rank (and that in an engine that does not know under-promotion...)

The promotion choice is an interesting problem in several ways - for instance if you wanted to play this as a shuffle-variant. I suppose you could detect from the move counter in the FEN that it represents the starting position, but then what do you do if it isn't: assume the normal promotion rules? Anyway, that's probably overthinking things at this stage.
A more obvious (though non-fatal) issue is selecting the promotion piece when entering a move in XBoard: there is no way to restrict it, so even if there is only one choice you have to pick the right piece. What happens if you pick the wrong one and the engine rejects the move? Will XBoard forfeit the engine because of a "false illegal move claim"? What if one engine rejects it and one does not?

Anyway, no point to adding underpromotions, since the promotion choice simply depends on the file, so the easy way to implement it is to just always use an array (indexed by file) that picks the promotion piece. Just fill it up with Q (or the equivalent) for other variants.
It does mean that the value of a passer is a (strong) function of the file it is on...

When I make the parent variant fairy, it has great difficulty winning KLK at 40/1min. At 40/5min it managed it. I still have the feeling that using the baring rule spoils part of the fun.

I for one can live without it, to be honest.
I'm also amazed that KLK is won, I wouldn't have thought that the Lion was a particularly strong piece (I have the move correct when I have it down as "HC" right?).

Any thought on piece values? I put the following more-or-less ad-hoc values in:

Code: Select all

Pawn      80
Rook     450
Bishop   300
Zebra    100
Lion     375
Gryphon  900
Unicorn  700

I guess we won't find out for sure until we can actually play games.

For added hilarity, here is a game played out by random moves:

Code: Select all

[Event "Computer Chess Game"]
[Site "vivaine.local"]
[Date "2016.01.07"]
[Round "-"]
[White "GA 0.1"]
[Black "GA 0.1"]
[Result "1/2-1/2"]
[TimeControl "40/10"]
[Variant "grandacedrex"]
[VariantMen "P:fmWfcF;B:B;R:R;Z:Z;A:FyafsF;L:HC;U:NmpafsyafW;K:KiDiA"]
[FEN "rluzbakbzulr/12/12/pppppppppppp/12/12/12/12/PPPPPPPPPPPP/12/12/RLUZBAKBZULR w Kk - 0 1"]
[SetUp "1"]

{--------------
r l u z b a k b z 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 Z B A K B Z U L R
white to play
--------------}
1. a5 Kg11 2. c5 Kg12 3. Kg2 b8 4. Ue2 Uf10 5. Bj3 Ab11 6. Lh1 Ac12 7. Bg3
b7 8. e5 d8 9. f5 Ab11 10. Za3 Kh11 11. Bf4 Bg11 12. Kg3 h8 13. Aj2 Kh10
14. h5 Ra10 15. Lhe1 Rc10 16. k5 c8 17. Ak3 Lh11 18. i5 Ki11 19. Af2 Ue8
20. Zc6 j8 21. l5 Bk6 22. Zxe9 Lbe12 23. Lh2 Rk10 24. Ae3 Uh4 25. Bxj8 Lxe9
26. Kxh4 Rd10 27. Uh6 Uh9 28. Ra2 Lb9 29. Kg5 Kj11 30. Rl2 Uxe5 31. Lhe1
Ac9 32. Uxe5+ Kj10 33. Uc2 Rh10 34. a6 Lk11 35. axb7 Ab11 36. Bi7 Zf10 37.
Ug8 cxb7 38. Le2 fxg8 39. Bk4 Ac6 40. Bi2 Le8 41. L2b2 Ld11 42. Kf6 Ri12
43. Bj3 La10 44. Rl1 Zd7 45. Lb5 Kj9 46. Le5 Rj12 47. Bi4 i8 48. Le2 Za5
49. Ak2 Be9 50. j5 Rhh12 51. Rb2 Bxl5 52. Rb1 Lh10 53. Lf4 Ki9 54. Rb3 Bi2
55. Lb1 Bxi5 56. Lbc4 Axd4 57. Lc7 Ai3 58. Bj3 Bg7+ 59. Lxg7 d7 60. Lf10+
Kj10 61. Rl5 Rhi12 62. Ra3 Ah2 63. Bd2 Ri10 64. Bj8 Ag3 65. k6 Bxj3 66.
Li11 d6 67. Ug5 Zc2 68. Uf3 Aj2 69. Ke7 Ak3 70. Rxl9 Aj1 71. Ra4 Lk11 72.
Kf6 Bxk2 73. Lc10 i7 74. Uh6 Ld9 75. Bxk9+ Kj11 76. Zk4 Ai6 77. Ra5 Ll8 78.
Uj7 Zf9 79. Lxh8 Lk5 80. Uh4 Ac7 81. c6 Lj8 82. Le7 Rf10 83. Ra8 Zf4 84.
Zh2 Rh10 85. b5 Ri10 86. Uj7 Rk12 87. Ra5 Rl10 88. Lxc7 Zc11 89. Rl5 i6 90.
Ul6 Bxh5 91. Rk5 Lc12 92. Lcd4 Rl8 93. Lc7 Rll12 94. Zk4 Zxc6 95. Lb10 Bg6
96. Bh12 d5 97. Uf11 Bk10 98. Lbe10 Bl9 99. Zi1 Rxh12 100. Ke6 ixj5 101.
Ud8 Bxg4 102. Lf10 Rf12 103. k7 Za3 104. Uh5 Zd1 105. Li11 Zb4+ 106. Kxd5
Be2 107. Ue1 Rd12+ 108. Ke5 Rl4 109. Rk4 Rd11 110. Rf4 Lc9 111. Ra8 Zf9
112. Ll11 Bd1 113. Ug4 Rd4 114. Re8 Kj12 115. Uf2 Zh6 116. f6 Bb3 117. Ul9+
Lk11 118. Rxl4 Rd7 119. Rc8 Lf9 120. Rlc4 Li8 121. R4c7 Rf7 122. Ld7 Bc2
123. Uxh6 Bh7 124. Ue2 Lil8 125. Li10 Lh11 126. Zf3 Rf8 127. Ud4 Lh8 128.
kxl8 Zxd7 129. Uf5 Zg5 130. Ua11 Ze2 131. Zh6 Li11 132. Li7 Bb1 133. Rc1
Lh8 134. Ri1 Lg5 135. Re8 Rxe8+ 136. Zxe8 Kj11 137. Rd1 Bi8 138. Lh4 Bh9
139. Rd4 Kk11 140. Rc4 b6 141. Lk3 Lf2+ 142. Kd4 Kj10 143. Zxb6 Bk6 144.
Ke3 Bh9 145. Uf5+ Ki10 146. Rg4 Kh11 147. Kxf2 g7 148. Ke3 Zh4 149. Ud4 Bd5
150. Ub1 a8 151. Kf4 Be4 152. Ud4 g6 153. Rg3 Kg10 154. Uf7 Kh10 155. Ke5
Zk6 156. Uc9 Ki11 157. Ug12+ Kh12 158. Re3 Zh4 159. Kxe4 g5 160. Kf5 Kh11
161. Rf3 Ki10 162. Ul6+ Ki11 163. Uk8+ Kj11 164. Ke4 Ze6 165. Ra3 Zc3 166.
Ze8 Kk11 167. Uh4 Zf5 168. Ke3 g8 169. Ra6 Zi3 170. Uk8 a7 171. Ul10 Zf5
172. Ud1 Kk12 173. Ra1 Kl11 174. Zh6 Kl12 175. Uj6 Zc7 176. Kd2 Kl11 177.
Zk8 Kl10 178. Uf11 j4 179. Ra3 Ze10 180. f7 Kl9 181. Kc1 jxk3 182. Ug9 Zc7
183. Kb2 Ze4+ 184. Kc2 Kl10 185. Rg3 Zb2 186. Ue8 Kk10 187. Rc3 g7 188. Rc5
Kj11 189. Ug9+ Kj10 190. Ui10 Kk10 191. Rc12 k2 192. Rc5 Ze4 193. Rxg5 Kl11
194. Zi11 g6 195. Kd3 Kl10 196. Uf6 Zc1 197. Ri5 k1=L 198. Ua2 Za4 199. Zg8
g5 200. Rl5 Lj4 201. Uf8 Lj1 202. Ud9 a6 203. Uf6 a5 204. Ri5 Li4 205. Zi11
Li7 206. Uk2 Lf8 207. Ri8 Lc8 208. Ri7 Lf8 209. Rk7 Lc7 210. Zl9 Ld4 211.
Ri7 Lc7 212. Ri5 Lc4 213. Ri3 Ld1 214. Ud10 Zd6 215. Ri4 Zg8 216. fxg8 La2+
217. Kd4 Kxl9 218. Ri2 Kk8 219. Ri10 Ld3 220. Kc3 Kk7 221. Ri11 Kj7 222.
Kc2 Le6 223. Ua8 Lf9 224. Kb3 Li8 225. Uc11 Lf7 226. Ri5 Kk7 227. Ri7+ Kk8
228. Ri1 Lg10 229. Rl1 Kj7 230. Rg1 Ld9 231. Rk1 Ki8 232. g9 Kj7 233. Rj1+
Kk7 234. Re1 La9 235. g10 Ld10 236. Uj5+ Kl7 237. Kc2 La9 238. Kd1 Kk6 239.
Ub12 Kl7 240. Re4 La12 241. Rb4 g4 242. Rb3 Kk6 243. Ue8 a4 244. Ud10 Kk5
245. Uj5 Kl5 246. Uk3+ Kk6 247. Rb1 Lb9 248. Uj1 g3 249. Rb2 Kk7 250. Ug5
La6 251. g11 Kj8 252. l9 La9 253. Ue8 Ki9 254. Uk3 Ki8 255. Ud11 Kh9 256.
l10 Lb6 257. Rk2 Le7 258. Rj2 Lf4 259. Ug7+ Ki9 260. Uj3 Ki10 261. Rc2 Li4
262. Rd2 g2 263. Kc1 Kj10 264. Ug5 Ll3 265. Ua10 Ki11 266. Uc9 Ki12 267.
Ue8 Ll6 268. Uh6 Ki11 269. Uf9+ Kj11 270. Uc7 a3 271. Uxg2 Li6 272. Kd1
Kk10 273. Ue3+ Kxl10 274. Rb2 Lf5 275. Rj2 Kk10 276. Ua8 Kl10 277. g12=A
Lc6 278. Uc5 Lf5 279. Ug8 Le8 280. Ah4 Lh9 281. Rj3 Lg6 282. Axa3 Kl9 283.
Uj10+ Kk10 284. Ke2 Lj6 285. Ac4 Lj9 286. Re3 Kk11 287. Ad5 Lk6 288. Ae10+
Kxj10 289. Re7 Lh5 290. Al9+ Kk9 291. b6 Lk4 292. Kf1 Lh4 293. Ak6 Le5 294.
Rd7 Lf2 295. Aj10+ Kl8 296. Rd4 Lc2+ 297. Ke1 Lb5 298. Rd10 La2 299. Af11
Ld1 300. Kd2 Kk7 301. Ag12 Kj7 302. Af9 Lg1+ 303. Kc2 Ki7 304. Rf10 Ld1
305. Ag5 Lc4 306. Al4 Lc1 307. Rj10 Kh8 308. Ac3 Lb4 309. Kd3 Le3 310. Ab5
Ki7 311. Ah6+ Kh8 312. Rj1 Lb2 313. Aj7+ Ki7 314. Ai4 Ki6 315. Ak3 Lb5 316.
Re1 Lb8 317. Re10 Kh5 318. Rh10+ Ki6 319. Rh6+ Ki5 320. Rl6 Lc11 321. Kd4
Kh5 322. Ag2+ Kg4 323. Ah11+ Kh3 324. Ag5+ Ki3 325. Rl12 Lf10 326. Af7 Li10
327. Ab8 Lf11 328. Ac5 Li12 329. Kc3 Kj3 330. Ad11 Lh9 331. Rd12 Kk3 332.
Ae5 Le9 333. Af7 Kk4 334. Rd10 Kl5 335. Ad6+ Kl4 336. Rg10 Lf12 337. Aa7
Lg9 338. Re10 Kl3 339. Ab8 Lh12 340. Kd3 Lk11 341. Ad7 Lj8 342. Rk10
{Xboard adjudication: 50-move rule} 1/2-1/2

[Evert]

When I make the parent variant fairy, it has great difficulty winning KLK at 40/1min. At 40/5min it managed it. I still have the feeling that using the baring rule spoils part of the fun.

[d]8/4k3/2N5/3K4/8/8/8/8 w
Knight represents Lion

1. Ke5 Kd8 2. Lf7 Kd7 3. Kd5 Ke7 4. Lc7 Kd7 5. Ld4+ Ke8 6. Ke6 Kd8 7. Kd6 Ke8 8. Lc7 Kd8 9. Lf7 Ke8 10. Lc8 Kd8 11. Ld5#

Here's SjaakII's analysis of this position. It's not exactly spotless (it continues to bounce around after announcing mate, so it seems to think a better mate is possible but it doesn't find it):

Code: Select all

  2.    0.00          38  +3.91   1. Ke5    Kd7   
  3.    0.00          92  +3.98   1. Ke5    Kf8    2. Kd6   
  4.    0.00         277  +4.00   1. Ke5    Kf8    2. Lf5    Kf7    3. Kd6   
  5.    0.01         628  +3.99   1. Ke5    Kf8    2. Ld3    Kf7    3. Le6   
  6.    0.01        1333  +4.00   1. Ke5    Kf8    2. Ld3    Kg7    3. Ld6    Kh8    4. Lg5    Kh7   
  7.    0.02        2529  +3.98   1. Ke5    Kf8    2. Ld3    Kg7    3. Ld6    Kf7    4. Lg5    Kg6   
  8.    0.02        4214  +4.03   1. Ke5    Kf8    2. Ld3    Kg7    3. Ld6    Kh6    4. Ke6    Kh7    5. Lg5   
  9.    0.03        8311  +4.02   1. Ke5    Kf8    2. Kf6    Kg8    3. Lf5    Kh8    4. Le8    Kg8    5. Ld5    Kh8    6. Lg5    Kh7   
 10.    0.06       16953  +4.03   1. Ke5    Kd8    2. Kd6    Kc8    3. Lf5    Kb8    4. Lc4    Ka7    5. Ld7    Kb6    6. Ke6   
 11.    0.08       24335  +4.06   1. Ke5    Kd8    2. Kd6    Kc8    3. Ld3    Kb7    4. Le6    Ka8    5. Kc6    Kb8    6. Lb5    Ka7    7. Le5   
 12.    0.11       37561  +3.99   1. Ke5    Kd8    2. Kd6    Kc8    3. Ld3    Kb7    4. Kc5    Kc7    5. Le6    Kd7    6. Kd5    Kc7   
 13.    0.14       52142  +4.04   1. Ke5    Kd8    2. Kd6    Kc8    3. Ld3    Kb7    4. Le6    Ka6    5. Kc6    Ka5    6. Lb7    Ka6    7. Le7    Ka7   
 14.    0.18       66347  +4.05   1. Ke5    Kd8    2. Kd6    Kc8    3. Ld3    Kb7    4. Le6    Ka6    5. Kc6    Ka5    6. Lb7    Ka6    7. Le7    Ka7    8. Kd6   
 15.    0.24       96089  +4.06   1. Ke5    Kd8    2. Kd6    Kc8    3. Ld3    Kb7    4. La3    Ka8    5. Kc7    Ka7    6. Kc6    Ka8    7. Ld4    Ka7    8. Ld7    Kb8   
 16.    0.36      152320  +4.07   1. Ke5    Kd8    2. Kd6    Kc8    3. Ld3    Kb7    4. La3    Ka8    5. Kc7    Ka7    6. Kc6    Ka8    7. Ld4    Ka7    8. Ld7    Kb8    9. Kd6   
 17.    0.47      205100  +4.07   1. Ke5    Kd8    2. Kd6    Ke8    3. Ke6    Kf8    4. Kf6    Ke8    5. Lf7    Kd7    6. Ke5    Ke8    7. Ke6    Kd8    8. Lg4    Kc7    9. Ld5   
 18.    0.64      285522  +4.06   1. Ke5    Kd8    2. Kd6    Ke8    3. Ke6    Kf8    4. Kf6    Ke8    5. Lf7    Kd7    6. Ke5    Ke8    7. Ke6    Kd8    8. Kd6    Ke8    9. Lc7    Kd8   
 19.    0.81      373480  +4.06   1. Ke5    Kd8    2. Kd6    Ke8    3. Ke6    Kf8    4. Kf6    Ke8    5. Lf7    Kd7    6. Ke5    Ke8    7. Ke6    Kf8    8. Lf4    Kg8    9. Kf6    Kh8    10. Le7    Kg8   
 20.    0.91      423450  +4.07   1. Ke5    Kd8    2. Kd6    Ke8    3. Ke6    Kf8    4. Kf6    Ke8    5. Lf7    Kd7    6. Ke5    Ke8    7. Ke6    Kf8    8. Lf4    Kg8    9. Kf6    Kh8    10. Le7    Kg8    11. Ke6   
 21.    1.14      550029  +4.08   1. Ke5    Kd8    2. Kd6    Ke8    3. Ke6    Kf8    4. Kf6    Ke8    5. Lf7    Kd7    6. Ke5    Ke8    7. Ke6    Kf8    8. Lf4    Kg8    9. Kf6    Kh8    10. Le7    Kg8    11. Ke6    Kg7   
 22.    1.40      687754  +4.08   1. Ke5    Kd8    2. Kd6    Ke8    3. Ke6    Kf8    4. Kf6    Ke8    5. Lf7    Kd7    6. Ke5    Ke8    7. Ke6    Kf8    8. Lf4    Kg8    9. Kf6    Kh7    10. Le7    Kg8    11. Ke6    Kg7    12. Kd6   
 23.    1.73      872993  +4.08   1. Ke5    Kd8    2. Kd6    Ke8    3. Ke6    Kf8    4. Kf6    Ke8    5. Lf7    Kd7    6. Ke5    Ke8    7. Ke6    Kf8    8. Lf4    Kg8    9. Kf6    Kh7    10. Le7    Kg8    11. Lb8    Kh8    12. Le8    Kg8    13. Ld5   
 24.    2.06     1062444  +4.08   1. Ke5    Kd8    2. Kd6    Ke8    3. Ke6    Kf8    4. Kf6    Ke8    5. Lf7    Kd7    6. Ke5    Ke7    7. Le4    Kd8    8. Kd6    Ke8    9. Ke6    Kf8    10. Kf6    Kg8    11. Lh5    Kh7    12. Le5    Kh8    13. Le8    Kg8    14. Ld5   
 25.    3.19     1728008  +4.07   1. Ke5    Kd8    2. Kd6    Ke8    3. Ke6    Kf8    4. Kf6    Ke8    5. Lf7    Kd7    6. Ke5    Ke7    7. Le4    Kd8    8. Kd6    Ke8    9. Ke6    Kf8    10. Kf6    Kg8    11. Lh5    Kh7    12. Le5    Kh8    13. Ke6    Kh7    14. Kd6   
 26.    4.19     2277651  +159.75   1. Ke5    Kd8    2. Kd6    Ke8    3. Ke6    Kf8    4. Kf6    Ke8    5. Lf7    Kd7    6. Ke5    Ke7    7. Le4    Kd8    8. Kd6    Ke8    9. Ke6    Kf8    10. Ld7    Ke8    11. Lg7    Kf8    12. Ld8    Ke8  

EDIT: it also appears to suffer from a truncated PV, which is odd...

[hgm]

The promotion choice is an interesting problem in several ways - for instance if you wanted to play this as a shuffle-variant. I suppose you could detect from the move counter in the FEN that it represents the starting position, but then what do you do if it isn't: assume the normal promotion rules? Anyway, that's probably overthinking things at this stage.

Well, historically it was not a shuffle variant, so basically you would be making a new variant with new rules, and you could pick them anyway you like. There doesn't seem to be anything against picking a promotion rule where every Pawn would promote to the piece that is in that file in the unshuffled game. In fact that makes it easier on the players, because they don't have to remember the initial setup. The purpose of shuffling is usually to void opening knowledge, not to change the end-game.

A more obvious (though non-fatal) issue is selecting the promotion piece when entering a move in XBoard: there is no way to restrict it, so even if there is only one choice you have to pick the right piece. What happens if you pick the wrong one and the engine rejects the move? Will XBoard forfeit the engine because of a "false illegal move claim"? What if one engine rejects it and one does not?

False illegal-move claims are only adjudicated in engine-engine games. With engine-defined variants there can never be any guards against engines disagreeing about the rules. If the GUI would judge promotions by rules it first obtained from the first engine, that engine could still do anything it wants, no matter how disagreeable to the second engine. In human-engine games the GUI just takes back the move. I agree it is a bit silly to offer the user a choice when there really is none. The same could be said when you are in check and there is only one legal evasion, though.

Anyway, no point to adding underpromotions, since the promotion choice simply depends on the file, so the easy way to implement it is to just always use an array (indexed by file) that picks the promotion piece. Just fill it up with Q (or the equivalent) for other variants.

In Fairy-Max I added a promotion board to replace the hard-coded bonus for pushing to 6th and 7th rank, which now contains both the bonus (64), as if it is Fairy-Max's equivalent of a Pawn PST, as well as a flag in the lowest bit to indicate the Pawn should promote there (the hard-coded last-rank test also didn't work anymore for ranks != 8). The action taken in that case is currently still the hard-coded one, and consists of adding the same constant to the score and the piece code, where the byte-size piece clips the high-order score bits so that it always becomes piece number 7 (for white; sometimes number 9 for black). As the push bonus of 64 would also be added to the piece code (as a reminder to take it away again when that Pawn is captured) it would make sense to simplify the code, and no longer distinguish promotion and pushing to 6th/7th rank, but just always tabulate what should be added to the piece code. It is a bit inconvenient that the score and piece code add the same thing (which was possible because the value difference between a Queen and a 7th-rank Pawn was about 0x300, which is invisible in the piece code).

Tabulating the piece/score-conversion constant makes it trivial to promote differently on different squares, and displaces the problem to the initialization of the array. For now I will probably accept that the score gained on promoting has to be a multiple of 256 cP. This already is a problem in any variant that does not promote to Queen.

It does mean that the value of a passer is a (strong) function of the file it is on...

Not as much as you might think. (Although promoting to a piece without mating potential definitely would be a bummer.) I once did a test in the design stage of Spartan Chess, when the Spartan army still used Chancellor, and was too strong. I tried to weaken it by restricting black promotion to Captain (WD), expecting this would lower the value of the Hoplit Pawns, which would then count 8 times. To my surprise it had no effect at all. In first approximation promotion just gains you a minor, as the opponnet will sac his minor to prevent you from keeping anything more valuable, or reaching a promotion square where you would obtain something more valuable. So the value of a Pawn depends much more on the lowest-valued piece of the opponent than on what it promotes to!

Whether lack of mating potential in the destined promotion piece suppresses the value depends a lot on what else you have, and really belongs in the section of scaling drawish material combinations. For that it would be important to distinguish the Pawns, for the base value it doesn't matter so much. Just like the Knight's value is hardly affected by the fact that KNNK is a draw. If there still are enough Pawns promoting to Zebra or Bishop will be just as winning as promoting to Lion, and promoting to Unicorn will probably win easier than promoting to Lion, even though the Lion has mating .potential and the Griffon lacks it.

I for one can live without it, to be honest.
I'm also amazed that KLK is won, I wouldn't have thought that the Lion was a particularly strong piece (I have the move correct when I have it down as "HC" right?).

That's right. According to my tablebase generator KLK is a general win. The Lion is not that weak; it has 12 move targets. Normally that would make it Rook class, but the fact that they are all range-3 steps weakens it, while the Rook benefits from the larger board. (Although that hurts the long leaper steps also less.) Most leapers with 12 moves have mating potential; if they attack 2 orthogonally adjacent squares 8 moves is often enough. The Lion attacks 3 adjacent squares, so it can even checkmate on an edge, and this actually seems the preferred mode.

Any thought on piece values?

I guessed the following:

Code: Select all

Pawn    111
Rook     481
Bishop   333
Zebra    222
Lion     444
Gryphon  830
Unicorn  700

But it is just a wild guess.

P.S.
I added two 10x10 variants to Fairy-Max: Mexican Chess (with two extra Camels), and Ciccolini's Chess, with Zebra and enhanced Bishops (that also have a Dabbabarider move).

[Evert]

The promotion choice is an interesting problem in several ways - for instance if you wanted to play this as a shuffle-variant. I suppose you could detect from the move counter in the FEN that it represents the starting position, but then what do you do if it isn't: assume the normal promotion rules? Anyway, that's probably overthinking things at this stage.

Well, historically it was not a shuffle variant, so basically you would be making a new variant with new rules, and you could pick them anyway you like. There doesn't seem to be anything against picking a promotion rule where every Pawn would promote to the piece that is in that file in the unshuffled game. In fact that makes it easier on the players, because they don't have to remember the initial setup. The purpose of shuffling is usually to void opening knowledge, not to change the end-game.

Good point.

It does mean that the value of a passer is a (strong) function of the file it is on...

Not as much as you might think. (Although promoting to a piece without mating potential definitely would be a bummer.) I once did a test in the design stage of Spartan Chess, when the Spartan army still used Chancellor, and was too strong. I tried to weaken it by restricting black promotion to Captain (WD), expecting this would lower the value of the Hoplit Pawns, which would then count 8 times. To my surprise it had no effect at all. In first approximation promotion just gains you a minor, as the opponnet will sac his minor to prevent you from keeping anything more valuable, or reaching a promotion square where you would obtain something more valuable. So the value of a Pawn depends much more on the lowest-valued piece of the opponent than on what it promotes to!

Sure.
I remember that I once tried to tune the saturated value of a passer (the value on the 7th rank) in Jazz, starting at just below Q. It eventually converged to just below N. I felt a bit silly when I thought about it afterwards.

I suppose it is true that what you promote into doesn't matter so much in the sense that even grabbing an extra minor is enough to win you the game (it would be quite funny to have an engine that underpromotes on principle) and only the outcome of the game is used to determine strength, not how you got there.

Even so, I would still think there's a difference in practice: you don't want to give up a Lion to prevent promotion to Zebra, but you might just want to avoid promotion to Gryphon or Unicorn.

In SjaakII, the value of the promotion piece contributes something like 5% to the base value of the pawn, but I don't remember if this was actually based on something more solid or whether it was just the outcome of numerology trying to fit empirical piece values. Possibly a bit of both.

Whether lack of mating potential in the destined promotion piece suppresses the value depends a lot on what else you have, and really belongs in the section of scaling drawish material combinations.

Sure. Unless you're in the very late endgame mate potential doesn't matter at all.

and promoting to Unicorn will probably win easier than promoting to Lion, even though the Lion has mating .potential and the Griffon lacks it.

I assume you meant Unicorn rather than Gryphon?

That's right. According to my tablebase generator KLK is a general win. The Lion is not that weak; it has 12 move targets. Normally that would make it Rook class, but the fact that they are all range-3 steps weakens it, while the Rook benefits from the larger board. (Although that hurts the long leaper steps also less.) Most leapers with 12 moves have mating potential; if they attack 2 orthogonally adjacent squares 8 moves is often enough. The Lion attacks 3 adjacent squares, so it can even checkmate on an edge, and this actually seems the preferred mode.

You're right, it's a lot stronger than I thought it was. I think I based my preconception on the idea that most long-range leapers are fairly weak, but of course the Lion is a compound leaper. Its long leap puts it outside of SjaakII's piece value guestimator, but if I try DN instead of HC it indeed values it as equivalent to a rook.

Any thought on piece values?

I guessed the following:

Code: Select all

Pawn    111
Rook     481
Bishop   333
Zebra    222
Lion     444
Gryphon  830
Unicorn  700

But it is just a wild guess.

Looks like the largest discrepancy is in the Zebra (which in my value list is almost worthless, which might be a bit unfair). The question then is whether Z+P ~ B or not. Should be easy enough to test (eventually).

P.S.
I added two 10x10 variants to Fairy-Max: Mexican Chess (with two extra Camels), and Ciccolini's Chess, with Zebra and enhanced Bishops (that also have a Dabbabarider move).

Mexican Chess I can add easily enough to SjaakII (which reminds me: do you have a working definition for Sac Chess that I can include?). Ciccolini's unfortunately not (the Dabbabarider is problematic).

[hgm]

Even so, I would still think there's a difference in practice: you don't want to give up a Lion to prevent promotion to Zebra, but you might just want to avoid promotion to Gryphon or Unicorn.

But you would not take that decision based on the value of the Pawn. That value is only important for decisions like which Pawn you would prefer to lose while promotion is still way beyond the horizon. At such a time it is likely much more important to worry about the chances that you can promote at all, rather than what you would get if you do.

I assume you meant Unicorn rather than Gryphon?

Oops, yes.

Looks like the largest discrepancy is in the Zebra (which in my value list is almost worthless, which might be a bit unfair). The question then is whether Z+P ~ B or not. Should be easy enough to test (eventually).

Don't take it too serious. The guess was based on one thing only, and that is measurement of the Camel value that I did long ago as one of the very first things I had Fairy-Max do. (And which actually triggered my involvement with WinBoard, for adding an extra piece type.) That value came at around 2.4 Pawn. But it was highly affected by issues that won't affect Grande Acedrex. Namely that the 8x8 board was so small that in the late end-game a Camel would always be lost without compensation, and that the FIDE setup allows Camels to attack, and even fork pieces trapped behind their own Pawns, and thus be quickly traded for something more valuable. I would think the Zebra about as strong as the Camel, and even on an infinite board somewhat weaker than Knight. On a 10-wide board there already is a difference of 50cP between a Knight and a lone Bishop, though. That could be worse on an even bigger board, although I do expect Zebras to suffer less from that then Knights.

It is an interesting balance of factors, that would deserve precise measuring: Z has some intrinsic (board-size-independent) disadvantage w.r.t. N due to poorer micro-manoeuvrability. But it has larger speed, which helps more (compared to sliders) on bigger boards.