CrazyWa bug / Kyoto Shogi

[Evert]

True, but things in general work more smoothly is they do not require communication with the engine. And it puts a rather large burden on the engine to support the highlight protocol. If the depth of a promotion zone can be adapted by just =N in the setup command, as it should for rectagular zones, this would be enormously simpler.

Did you load variants.txt?

Edit: sorry, this was meant to be a response to your other question (about the version that plays Kyoto).

[hgm]

Not really. But I did look in the file variants.txt, and the word 'kyoto' does not appear there.

[Evert]

Not really. But I did look in the file variants.txt, and the word 'kyoto' does not appear there.

My bad!
I apparently mis-remembered that Kyoto Shogi was included. Looking at my local set of files, I actually have two different definitions: one using Shogi-style promotions, one using Western-style promotions:

Code: Select all

Variant: Kyoto Shogi
Board: 5x5
XBoard pieces: "P^G^S^P.....GS.......^T...TKp^g^s^p.....gs.......^t...tk"
XBoard parent: "shogi"
FEN: "pgkst/5/5/5/TSKGP w 0 1"

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

Piece: Pawn 
Symbol: "P", "P,p" 
Move: step N 
Promotion: all, all, "+" 
Optional promotion: empty, empty

Piece: Rook 
Symbol: "+P", "+P,+p" 
Move: slide (H,V) 
Promotion: all, all, "P" 
Demotion: "P" 
Optional promotion: empty, empty

Piece: Tokin
Symbol: "T", "T,t" 
Move: aleap (1,0)|(-1,0)|(0,1)|(0,-1)|(1,1)|(-1,1)
Promotion: all, all, "+" 
Optional promotion: empty, empty

Piece: Lance
Symbol: "+T", "+T,+t"
Move: step 5N
Promotion: all, all, "T"
Demotion: "T"
Optional promotion: empty, empty

Piece: Silver general
Symbol: "S", "S,s"
Move: aleap (0,1)|(1,1)|(1,-1)|(-1,-1)|(-1,1)
Promotion: all, all, "+"
Optional promotion: empty, empty

Piece: Bishop
Symbol: "+S", "+S,+s"
Move: slide (D,A)
Promotion: all, all, "S"
Demotion: "S"
Optional promotion: empty, empty

Piece: Gold general
Symbol: "G", "G,g"
Move: aleap (1,0)|(-1,0)|(0,1)|(0,-1)|(1,1)|(-1,1)
Promotion: all, all, "+"
Optional promotion: empty, empty

Piece: Knight
Symbol: "+G", "+G,+g"
Move: aleap (1,2)|(-1,2)
Promotion: all, all, "G"
Demotion: "G"
Optional promotion: empty, empty

Rule: keep capture, allow drops, promote drop
Rule: repeat4 = draw 
Rule: perpetual = loss 

and

Code: Select all

Variant: Kyoto Shogi
Board: 5x5
XBoard pieces: "PNBR.....GS.......L...TKpnbr.....gs.......l...tk"
XBoard parent: fairy
FEN: "pgkst/5/5/5/TSKGP w 0 1"

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

Piece: Pawn 
Symbol: "P", "P,p" 
Move: step N 
Promotion: all, all, "R" 
Optional promotion: empty, empty

Piece: Rook 
Symbol: "R", "R,r" 
Move: slide (H,V) 
Promotion: all, all, "P" 
Demotion: "P" 
Optional promotion: empty, empty

Piece: Tokin
Symbol: "T", "T,t" 
Move: aleap (1,0)|(-1,0)|(0,1)|(0,-1)|(1,1)|(-1,1)
Promotion: all, all, "L" 
Optional promotion: empty, empty

Piece: Lance
Symbol: "L", "L,l"
Move: step 5N
Promotion: all, all, "T"
Demotion: "T"
Optional promotion: empty, empty

Piece: Silver general
Symbol: "S", "S,s"
Move: aleap (0,1)|(1,1)|(1,-1)|(-1,-1)|(-1,1)
Promotion: all, all, "B"
Optional promotion: empty, empty

Piece: Bishop
Symbol: "B", "B,b"
Move: slide (D,A)
Promotion: all, all, "S"
Demotion: "S"
Optional promotion: empty, empty

Piece: Gold general
Symbol: "G", "G,g"
Move: aleap (1,0)|(-1,0)|(0,1)|(0,-1)|(1,1)|(-1,1)
Promotion: all, all, "N"
Optional promotion: empty, empty

Piece: Knight
Symbol: "N", "N,n"
Move: aleap (1,2)|(-1,2)
Promotion: all, all, "G"
Demotion: "G"
Optional promotion: empty, empty

Rule: keep capture, allow drops, promote drop
Rule: repeat4 = draw 
Rule: perpetual = loss 

[hgm]

OK, thanks! I will try them out.

[hgm]

I played two games by hand (using the second definition) from the command line, and the good news is that there was never any disagreement of which moves were legal, or sudden score drops in CrazyWa that you would expect if the opponent made a move CrazyWa considered illegal. There seems to be a problem with Sjaak II's time management in this variant, though. I played at 40 moves/5 min, and often Sjaak uses 50-90% of its remaining time for a single move. Then it has to play the remaining moves very fast, so that CrazyWa could easily win both games.

E.g. in the game were Sjaak played sente (64MB hash)

Code: Select all

1. Pe2R Td4L 2. Sc2B Sc4B 3. Tb1L Lxd1T 4. Kxd1 N@c3 5. Kd2 Nxb1G 6. Bxb1S L@d5
7. Ke1 Bxe2S 8. Kxe2 R@e5 9. S@e4 Rxe4P 10. L@c1 Gc4N 11. Lxc4T Kxc4 12. N@b2 Kb
4 13. G@c4 Kb3 14. Sa2B Kc2 15. Bb3S Kc1 16. Sb4B L@e3#

It already squanders half its time on the second move:

Code: Select all

#[Kyoto Shogi] 1b>e5d4l

  2.    0.05        2867  +0.32   2. Sb2B   Lxd1T  3. Kxd1   Pa4R
  3.    0.08        3954  +0.32   2. Sb2B   Lxd1T  3. Kxd1   Pa4R
  4.    0.22       10386  -0.09   2. Sc2B   Sc4B   3. Tb1L   Pa4R
  5.  153.86     8650890  +0.02   2. Sc2B   Sc4B   3. Tb1L   Pa4R   4. Lb3T   Ld
3T
Time remaining 2:18.35
move Sc2B

It seems some search explosion occurs in iteration 5.

[GregNeto]

This was discussed a year ago, Evert released a Sjaak version without this problem.


http://www.talkchess.com/forum/viewtopi ... ight=kyoto

[hgm]

Thank you! I had forgotten all about that. That is, I remember having discussed what could be done in WinBoard, but I did not remember the Sjaak II problems. Apparently the fix never made it beyond the beta stage. This one also has Kyoto Shogi in its variants.txt file.

I downloaded Sjaak II 1.5.0 RC0, and this indeed has reasonable time usage at 40 moves / 5 min, and also reaches much higher depth (9-10 ply). I had it play two games against CrazyWa (hand-mediated from the command line):

Code: Select all

Sjaak II - CrazyWa (0-1):
1. Sc2+ Td4+ 2. Tb2+ Gc4+ 3. +Tb3+ +Txd1+ 4. +Sxd1+ +G@d3 5. Kc2 +Gxe1+ 6. T@b4
Kd4 7. T4xc4+ Se4+ 8. Kd2 Gxd1+ 9. G@c3 Ke5 10. Kxd1 +P@b1 11. Ke2 S@d4 12. +G@d2
+Pxb3+ 13. +Gxe4+ Kxe4 14. +S@c2 G@d3 15. Gxd3+ T@e3 16. Kd1 Sxd3+ 17. G@d2 Txd2+
18. Kxd2 G@e2 19. Kc3 +Sxc2+ 20. T@d4 Ke3 21. Kb4 Pb2+ 22. Kc5 +S@c3 23. Kd5
+Sxd4+ 24. +Tc5+ Sb3+ 25. Tc4+ G@c5#

CrazyWa - Sjaak II (1-0)
1. Pe2+ Te4+ 2. +Pc2+ Pa4+ 3. Pc3+ Gc4+ 4. Tb2+ Sd4+ 5. +Pxc4+ +Pxc4+ 6. G@b4 Kd5
7. Gxc4+ +P@c3 8. Sc2+ +Pxc2+ 9. Gxc2+ +S@e3 10. Kb1 +Sxb2+ 11. Kxb2 +T@b5
12. Kc3 +Sd2+ 13. Kxd2 +Te3+ 14. Kc3 +Tb4+ 15. Kxb4 Td2+ 16. T@d4#

No problems detected at either side. So the implementation of Kyoto Shogi in CrazyWa seems to work, and the ab-initio piece values reasonable enough to not 'sacrifice itself to death'.

Still, variants this different from usual are tricky; some of CrazyWa's search tricks definitely backfire in Kyoto Shogi. For instance, it prunes ' futile interpositions' as check evasions. These are interposing drops on a square that is unprotected. These are in general pointless, as the checking slider would simply renew the check by capturing the interposed piece. But in Kyoto Shogi (or micro-Shogi) this would alter the piece type, so that the piece doesn't deliver check anymore.

Some remarks on playing Sjaak II from the command line:
* The grey characters indicating the pieces on the board it prints are virtually invisible on the light-blue background.
* When it prints the time left, it doesn't force a leading zero on the seconds. So it uses formats like 4:1.56.

[Evert]

Thank you! I had forgotten all about that. That is, I remember having discussed what could be done in WinBoard, but I did not remember the Sjaak II problems. Apparently the fix never made it beyond the beta stage. This one also has Kyoto Shogi in its variants.txt file.

You know, I had quite forgotten about this too!
What's holding back Sjaak II 1.5 is a severe form of feature creep. I keep thinking of "just one more thing..." that I want to include.
The development version has added Janggi to its list of supported variants, but... I still want to make a tweak or two to the implementation.
Following that, there's a load of work I want to do to streamline the evaluation, so it can also be improved more (not that that is a major concern, Sjaak II will never really beat dedicated engines at the games they play).

No problems detected at either side. So the implementation of Kyoto Shogi in CrazyWa seems to work, and the ab-initio piece values reasonable enough to not 'sacrifice itself to death'.

Note though that the piece values in SjaakII are probably way off. You can check what they are using the "pieceinfo" command.

Still, variants this different from usual are tricky; some of CrazyWa's search tricks definitely backfire in Kyoto Shogi. For instance, it prunes ' futile interpositions' as check evasions. These are interposing drops on a square that is unprotected. These are in general pointless, as the checking slider would simply renew the check by capturing the interposed piece. But in Kyoto Shogi (or micro-Shogi) this would alter the piece type, so that the piece doesn't deliver check anymore.

I'm sure there are a ton of little things like that in Sjaak II - even more so than in CrazyWa (although on the flip side, it should make fewer assumptions on what will turn out to be futile).

Some remarks on playing Sjaak II from the command line:
* The grey characters indicating the pieces on the board it prints are virtually invisible on the light-blue background.
* When it prints the time left, it doesn't force a leading zero on the seconds. So it uses formats like 4:1.56.

It's hard to pick colours that stand out well using only the standard ANSI colour codes. It looks fine on my display, but that doesn't mean it will for everyone else. I could change it to bright white (high intensity white) rather than the current value, if that helps?
I'll look at the leading-zero issue with the seconds. Shouldn't be too hard to fix, although I'm not sure if you can force a leading zero on a float (if you can do that, the fix is trivial).

[hgm]

Note though that the piece values in SjaakII are probably way off. You can check what they are using the "pieceinfo" command.

It assigns a very low value to the Pawn. I suppose it doesn't sufficiently account for the fact that even the weak pieces have a lot of 'latent' value because they will turn into strong pieces after they move. Also the dependence on the location for irreversible pieces seems a very important aspect that it might not take into account sufficiently.

... I'm not sure if you can force a leading zero on a float (if you can do that, the fix is trivial).

Good point. Perhaps you should simply not print the fraction if the time > 1 min, and not the minutes if it is < 1 min.

Bright white gives no problem on either square shade. Is there a reason for avoiding pure black for the black pieces? I suppose yellow would stand out pretty well against the square colors you use.

[Evert]

It assigns a very low value to the Pawn. I suppose it doesn't sufficiently account for the fact that even the weak pieces have a lot of 'latent' value because they will turn into strong pieces after they move. Also the dependence on the location for irreversible pieces seems a very important aspect that it might not take into account sufficiently.

Yes.
I suppose it should do some sort of average between the piece values for promotion/demotion pairs, but the situation in Kyoto Shogi is pretty unique. I would probably want to detect whether a piece always has to promote, and then do some sort of average between its value and the value of the target piece. Thing is, if the promoted form of the piece promotes to the weaker version again, that creates a cyclic dependency chain that would have to be detected and dealt with explicitly.

... I'm not sure if you can force a leading zero on a float (if you can do that, the fix is trivial).

Good point. Perhaps you should simply not print the fraction if the time > 1 min, and not the minutes if it is < 1 min.

Yes, that's also a reasonable alternative - although there is of course plenty of space on the terminal to show both, so the only consideration is clarity.

Bright white gives no problem on either square shade. Is there a reason for avoiding pure black for the black pieces? I suppose yellow would stand out pretty well against the square colors you use.

The black pieces are supposed to be pure black. They're not for you?
Yellow instead of White would stand out well (but would probably hurt my eyes ), perhaps the best thing to do would be to make this configurable by the user somehow; that way users who don't like the defaults can change them.
Unrelated, the difficulty for me is that the Windows console doesn't support ANSI sequences, so I'm emulating those. I suppose I should double-check that this works as expected.