SjaakII 1.0 RC1

Discussion of anything and everything relating to chess playing software and machines.

Moderator: Ras

User avatar
Evert
Posts: 2929
Joined: Sat Jan 22, 2011 12:42 am
Location: NL

Re: SjaakII 1.0 RC4

Post by Evert »

myfish wrote:Actually, it seems 'I' may have misunderstood the way the variants are done.

Code: Select all

   game->add_piece_type( fk,  fk, kf, pz, "",     "Phoenix",    "K,k", "K");
   game->add_piece_type( ff,  ff, 0,  pp, "+",    "Falcon",     "F,f", "F");
   game->add_piece_type( fc,  fc, 0,  pz, "",     "Crane",      "C,c", "C");
   game->add_piece_type(flq, flq, 0,  pz, "",     "Left quail", "L,l", "L");
   game->add_piece_type(frq, frq, 0,  pz, "",     "Right quail","R,r", "R");
   game->add_piece_type( fp,  fp, 0,  pz, "",     "Pheasant",   "P,p", "P");
   game->add_piece_type( fs,  fs, pf, pp, "+",    "Swallow",    "S,s", "S");
   game->add_piece_type( fg,  fg, 0,  pz, "",     "Goose",      "+S,+s","+S");
   game->add_piece_type( fe,  fe, 0,  pz, "",     "Eagle",      "+F,+f","+F");

   game->start_fen = strdup("rpckcpl/3f3/sssssss/2s1S2/SSSSSSS/3F3/LPCKCPR [-] w 0 1");
   game->xb_setup = strdup("(S.....FLR.C+.....+.PKs.....flr.c+.....+.pk) 7x7+6_shogi");


From variants.h

Are we saying we can define ANY single letter code to correspond to the Xboard FEN?
Yes.

However, you'll notice that there are three distinct names for each piece: what white pieces are called in position (FEN) strings, what black pieces are called there (typically the lower-case version of the white character) and what symbol should be used for SAN output of moves (typically the same as the white piece name, but pawn-likes are typically an exception). The latter is also used to identify the piece type by promotion.
In Yari, we have Yari Bishop, Yari Rook and just Rook for example so you couldn't use R for rook, nor Y for Yari. Thinking about dai and chu etc 2 piece naming for pgn etc would open the doors but I'm no programmer and this would likely break everything right. But surely, lets take the Tori example.

L = Left Quail. I want to see LQ in the pgn and move list. So why can't we just assign LQ to the variable 'L' or isn't it that simple ?
I think SjaakII will work correctly if you use more than one character for the piece name (as it appears in SAN output), at least as long as nothing promotes to this piece type. It will not work correctly if the white/black identifiers in position strings are not single characters. Certainly none of the code was written with piece-IDs longer than a single character in mind.

There are two exceptions to this: the first character may be "+" to indicate this is the promoted version of some other piece type, or the second character may be "~" to indicate that this piece type demotes when captured (what it demotes to is not specified, but reconstructed from the promotion rules).

In general it is quite hard to describe positions with mixed single/double character piece identifiers. Imagine a variant that has a Left Quail (LQ), a Lance (L) and a Queen (Q). Or worse, a Phoenix (Ph), a Pawn (P ) and a Horse (H): is "Ph" a phoenix, or a white pawn next to a black horse?
HGM is better equipped to discuss the issues there than I am though.

For variants with many different piece types, it's no longer simply a matter of cosmetics: if there are more than 26 piece types, you need to resort to something other than single character identifiers for pieces. For SjaakII that's not going to be an issue, since it can't handle more than 16 piece types per variant (not sure if I documented that limitation; I probably should).
User avatar
Evert
Posts: 2929
Joined: Sat Jan 22, 2011 12:42 am
Location: NL

Re: SjaakII 1.0 RC4

Post by Evert »

myfish wrote: [Date "2015.02.28"]
[Round "-"]
[White "Sjaak II 1.0 RC5"]
[Black "Shokidoki tori3"]
[Result "0-1"]
[TimeControl "600"]
[Variant "shogi"]
[VariantMen "+F:KbRfBbF2;P:bFfD;+f:KbRfBbF2"]
[FEN "rpckcpl/3f3/sssssss/2s1S2/SSSSSSS/3F3/LPCKCPR[-] w 0 1"]
[SetUp "1"]

{--------------
r p c k c p l
. . . f . . .
s s s s s s s
. . s . S . .
S S S S S S S
. . . F . . .
L P C K C P R
white to play
--------------}
1. cxc4 {+0.01/17} exe4 {-0.48/14 38} 2. exe4 {-0.02/17 32} cxc4
{-0.20/13 16} 3. Cc2 {-0.06/18 28} S@b2 {+2.16/13 15}
{False illegal-move claim} 0-1
Ah, I see. I mis-read the rule about pawn (swallow) drops in Tori: I thought it was the same as in Shogi (not allowed to drop if there is an unpromoted pawn on the same file), but it's annoyingly different (not allowed to drop if there are two unpromoted pawns on the same file). That's annoying. I'll need to think about how to fix that.
User avatar
Evert
Posts: 2929
Joined: Sat Jan 22, 2011 12:42 am
Location: NL

Re: SjaakII 1.0 RC4

Post by Evert »

Evert wrote: Ah, I see. I mis-read the rule about pawn (swallow) drops in Tori: I thought it was the same as in Shogi (not allowed to drop if there is an unpromoted pawn on the same file), but it's annoyingly different (not allowed to drop if there are two unpromoted pawns on the same file). That's annoying. I'll need to think about how to fix that.
Ok, I fixed it. I'm not entirely happy with it (it requires another per-piece property) but it doesn't look too bad. This is the patch (in case you want to apply it to your local version):

Code: Select all

Index: ../include/piece_rules.h
===================================================================
--- ../include/piece_rules.h	(revision 344)
+++ ../include/piece_rules.h	(working copy)
@@ -53,6 +53,7 @@
    pt.demotion[n]             = n;
    pt.piece_promotion_choice[n] = 0;
    pt.pzset[n]                = false;
+   pt.piece_drop_file_maximum[n] = 1;
    if (piece_flags & PF_ROYAL) {
       pt.piece_maximum[n][WHITE] = 1;
       pt.piece_maximum[n][BLACK] = 1;
Index: ../include/piece_types.h
===================================================================
--- ../include/piece_types.h	(revision 344)
+++ ../include/piece_types.h	(working copy)
@@ -91,6 +91,7 @@
    uint16_t    piece_flags[MAX_PIECE_TYPES];
    int8_t      demotion[MAX_PIECE_TYPES];
    uint8_t     piece_maximum[MAX_PIECE_TYPES][NUM_SIDES];
+   uint8_t     piece_drop_file_maximum[MAX_PIECE_TYPES];
    bool        pieces_can_win[MAX_PIECE_TYPES][MAX_PIECE_TYPES];
 
    int         val_perm[MAX_PIECE_TYPES];
Index: ../include/variants.h
===================================================================
--- ../include/variants.h	(revision 344)
+++ ../include/variants.h	(working copy)
@@ -987,10 +987,13 @@
    game->add_piece_type(flq, flq, 0,  pz, "",     "Left quail", "L,l", "L");
    game->add_piece_type(frq, frq, 0,  pz, "",     "Right quail","R,r", "R");
    game->add_piece_type( fp,  fp, 0,  pz, "",     "Pheasant",   "P,p", "P");
+   int st =
    game->add_piece_type( fs,  fs, pf, pp, "+",    "Swallow",    "S,s", "S");
    game->add_piece_type( fg,  fg, 0,  pz, "",     "Goose",      "+S,+s","+S");
    game->add_piece_type( fe,  fe, 0,  pz, "",     "Eagle",      "+F,+f","+F");
 
+   game->pt.piece_drop_file_maximum[st] = 2;
+
    game->start_fen = strdup("rpckcpl/3f3/sssssss/2s1S2/SSSSSSS/3F3/LPCKCPR [-] w 0 1");
    game->xb_setup = strdup("(S.....FLR.C+.....+.PKs.....flr.c+.....+.pk) 7x7+6_shogi");
    game->name = strdup("Tori Shogi");
Index: ../include/movegen.h
===================================================================
--- ../include/movegen.h	(revision 344)
+++ ../include/movegen.h	(working copy)
@@ -1836,8 +1836,10 @@
 
                if (piece_types->piece_flags[n] & PF_DROPONEFILE) {
                   for (int f = 0; f<bitboard_t<kind>::board_files; f++) {
-                     if (!(own & board->bbp[n] & bitboard_t<kind>::board_file[f]).is_empty())
-                        drops &= ~bitboard_t<kind>::board_file[f];
+                     bitboard_t<kind> bb = own & board->bbp[n] & bitboard_t<kind>::board_file[f];
+                     if (!bb.is_empty())
+                        if (piece_types->piece_drop_file_maximum[n] < 2 || bb.popcount() >= piece_types->piece_drop_file_maximum[n])
+                           drops &= ~bitboard_t<kind>::board_file[f];
                   }
                }
 
For reference, my perft6 (total number of legal positions that can be reached from the starting position after 6 half-moves) is

Code: Select all

 1         17  0.00    320754.72nps
 2        288  0.00   1391304.35nps
 3       5445  0.00   1829022.51nps
 4     104381  0.03   3834012.86nps
 5    2211100  0.51   4359243.80nps
 6   47928981 11.69   4099170.83nps
It may be worth verifying against Shokidoki (if it lets you calculate perft).
myfish
Posts: 131
Joined: Sat Feb 07, 2015 3:17 pm

Re: SjaakII 1.0 RC4

Post by myfish »

In general it is quite hard to describe positions with mixed single/double character piece identifiers. Imagine a variant that has a Left Quail (LQ), a Lance (L) and a Queen (Q). Or worse, a Phoenix (Ph), a Pawn (P ) and a Horse (H): is "Ph" a phoenix, or a white pawn next to a black horse?
HGM is better equipped to discuss the issues there than I am though.
Yes, I understand most of the previous.
I don't really want to distract hgm from the kifu stuff he's doing right now and my desire to build opening books from said files but the above '2 latter naming convention' would be nice.

Not essential, just nice and something you guys could look at maybe. Of course, we have to really look at the people playing odd variants. Of the awkward ones, Tori must be up there with those 'most played'.

And yes, I was VERY confused for a long time early in my Tori days until I read the aforementioned book.

I skipped over the pawn (swallow) stuff thinking I was being clever. To this day I don't know HOW I missed legal 2 swallow drops in a file but i did.

A swallow cannot be dropped into the same file (vertical column) as two other unpromoted swallows controlled by the same player. (A goose, or promoted swallow, does not count as a swallow when considering this drop restriction.)


So this rule is different.

A swallow cannot be dropped where the opponent would have no way to prevent his phoenix being captured on the next move. In other words, a swallow cannot be dropped to give immediate mate.

This rule follows shogi convention.

Who ever invented variants should be shot... LOL

I will apply the patches. Thank-you for your time.
User avatar
hgm
Posts: 28507
Joined: Fri Mar 10, 2006 10:06 am
Location: Amsterdam
Full name: H G Muller

Re: SjaakII 1.0 RC4

Post by hgm »

Well, like Evert already remarked, for variants with more than 26 piece types (or 52, if you can use the + prefix to duplicate them), the single-letter ID would not work.

But the problem is that XBoard is currently not suitable for multi-letter piece ID at all. It would have to be changed in many places: PGN generator and parser, position encoding, pieceToCharTable. For some of these it would be really hard to conceive a system that works with variable-length naming, even apart from implementing it. One way to do it would be to have a number of prefixes similar to '+', or suffixes, e.g. A, A' and A" could define 3 different piece types. (And in FEN the black pieces could then be senoted a, a' and a") This has reasonable readability, and stretches the limit to 78 (x 2 if you also have promoted versions).

Of course this is not really what you are asking for. But it would be reasonably simple to implement, as the code for processing FENs, moves and pieceToCharTables could just collaps letter + suffix into one unique code when reading, which again is expanded on printing.

I am not convinced that the TSA notation you show (Swallow = Sw) is any better than PGN/SAN (Swallow = S). The problem of same first letter is well known from Chess, and no one really complains that Knight = N. In fact I think the TSA notation is ill designed: there is no need for multi-character ID, and having the second letter lower case is awful, as it interferes with disambiguation. It either forces you to always write a full to-square, or put an extra separator beween piece ID and square. Like Ph-f2e. It is just ugly.

Note that an engine could print anything as its analysis (as long as it gives the moves it actually plays in standard notation), but that it would break part of the XBoard functionality to use a non-standard format there. (You can no longer walk through the engine PV.)

@Evert:

Alas, Shokidoki doesn't do perfts. In Shogi they would not be correct anyway, as it would not allow some pieces to under-promote.
myfish
Posts: 131
Joined: Sat Feb 07, 2015 3:17 pm

Re: SjaakII 1.0 RC4

Post by myfish »

hgm wrote:
I am not convinced that the TSA notation you show (Swallow = Sw) is any better than PGN/SAN (Swallow = S). The problem of same first letter is well known from Chess, and no one really complains that Knight = N.
In this case, clearly no issue.

It actually isn't an issue until you need to perhaps print the pgn in a blog or something when having the actual piece names in use is beyond preferable.

I just wondered how it worked.
User avatar
Evert
Posts: 2929
Joined: Sat Jan 22, 2011 12:42 am
Location: NL

Re: SjaakII 1.0 RC3

Post by Evert »

hgm wrote: BTW, to optimize Sjaak you could forbid deferral in its search for pieces that promote in an upward-compatible way. Replace their mandatory-promotion mask by all-one masks during loading the pieces. You could keep the true masks for use during legality testing of input moves. I noticed that currently it often defers if it thinks the piece will be immediately captured, or if it intends to trade it anyway. In Shokidoki I don't generate deferrals of L on last 2 ranks and P, B, R for Shogi.
Running a sanity-test on this now, not generating pointless deferrals in the seach seems to be worth a 10% reduction in nodes at constant depth early on. I'm not sure what sort of change in playing strength that translates to, but it shouldn't hurt (the sanity test is to make sure that I really didn't mess up here).
User avatar
hgm
Posts: 28507
Joined: Fri Mar 10, 2006 10:06 am
Location: Amsterdam
Full name: H G Muller

Re: SjaakII 1.0 RC4

Post by hgm »

The more I think about it, the more I like this system of non-alphabetic suffixes to single letters for extending the number of piece types in SAN. This causes far less problems than variable-lenth piece IDs made of letters. The large Shogi variants seem the most extreme examples. Their requirement are:

Chu: 21 piece types (+ 18 promoted)
Dai: 29 piece types
Dai Dai: 64 piece types
Maka Dai Dai: 50 piece types
Tai: 93 piece types
Taikyoku: 209 piece types.

When we forget about Taikyoku (which would also pose problems for indicating square coordinates, with its 36x36 board), four times the alphabet would do. Perhaps B, B', B" and B!, when I pick symbols that look narrow in proportional spacing, and are intuitively interpreted as suffixes. Back-quote is mich wider (B`B`B"B"B'B'B!B!B).

The only problem I see is in the FEN tag of a PGN game. PGN tags have syntax [Name "value"], and using double quotes in the 'value' part would cause ambiguous parsing. Especially since FENs can also contain brackets [] for the holdings. If one would have to escape all double quotes in a FEN by preceding them with a backslash, it would lose all its appeal.

But I guess the PGN parser could be made smart enough to treat the FEN tag in a special way, looking for the combination "] to terminate it, after balancing brackets in the FEN. (I.e. the first "] after a [ should not betaken as closure of the tag.

An alternative would be to not use " as suffix at all, (but this would really be a pity, as it is such an obvious choice), or 'escape' them by replacing them with back-quotes only there (and use double quotes in SAN). OTOH, perhaps using back-quotes as one of the possible suffixes can have an advantage of intuitive interpretation: Many of the piece types occurring in these large Shogi variants are the flipped versions of other pieces. Like Gold, Silver or Copper moving backwards. Denoting those by G`, S` or C` would be kind of natural. For laterally symmetric pairs, such as the Tori Quails, Q' and Q" could be natural assignments (where single quotes always indicate 'left', and double quotes 'right'). Exclamation-point suffixes could be reserved for the more important pieces, such as Hook movers (H!, G!, C! for Hook Mover, Goblin and Capricorn), jumping generals in Tenjiku (G!, V!, R!, B! for Great, Vice, Rook and Bishop General), multi-capturers (L!, F! for Lion Dog and Fire Demon).

By having a set of suffixes larger than strictly needed, it would become possible to associate each of them with a certain class of piece types, which would greatly help human interpretation.
User avatar
Evert
Posts: 2929
Joined: Sat Jan 22, 2011 12:42 am
Location: NL

Re: SjaakII 1.0 RC4

Post by Evert »

hgm wrote:

Code: Select all

[Event "Computer Chess Game"]
[Site "ONTWIKKELLAPTOP"]
[Date "2015.02.26"]
[Round "4"]
[White "Shokidoki euro"]
[Black "Sjaak II 1.0 RC5"]
[Result "1-0"]
[TimeControl "40/1200"]
[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. g4 {+0.32/15} b5 {-0.11/17 23} 2. Gc2 {+0.32/15 16} Gf7 {-0.09/16 23} 3.
Be2 {+0.08/15 16} Gde7 {+0.10/15 24} 4. Kd2 {+1.36/15 19} f5 {+0.23/16 24}
5. g5 {+1.48/15 24} gxg5 {+0.26/16 31} 6. Rxg5 {+0.88/14 47} e5
{+0.27/14 31} 7. Nf1 {+1.16/12 19} P@g6 {+0.99/14 31} 8. Rg1 {+1.32/14 19}
b4 {+1.11/16 21} 9. bxb4 {+0.84/14 17} Be6 {+1.04/16 31} 10. Nc1
{+0.48/13 35} Ba2+ {+1.16/15 27} 11. P@g5 {+0.72/12 16} gxg5 {+1.79/13 16}
12. Rxg5 {+0.16/13 23} +Be6 {+1.40/13 23} 13. d4 {+1.12/12 27} Rxb4
{+2.49/12 30} 14. Bc4 {+1.20/11 17} +Bf6 {+2.36/12 45} 15. Rg1
{+0.96/10 16} e4 {+2.53/11 31} 16. P@g6 {+1.00/10 21} Bh8 {+3.15/10 18} 17.
P@b3 {+0.24/10 31} Rb7 {+3.50/12 32} 18. Ge2 {+0.00/10 17} +Bxd4
{+3.33/11 20} 19. Ged3 {-0.48/10 44} exe3+ {+4.33/11 38} 20. Gxe3
{-0.80/11 43} +Bb6 {+4.43/11 27} 21. P@e6 {+0.72/9 14} Gef6 {+5.47/11 33}
22. Rg2 {-0.32/9 15} Nf8 {+6.17/11 28} 23. b4 {-1.12/9 30} Nxe6
{+6.15/11 33} 24. b5 {-1.36/9 20} +Ba7 {+6.22/11 33} 25. Bb3 {-1.32/9 45}
Rxb5 {+7.43/11 20} 26. c4 {-1.80/9 20} d5 {+7.58/10 21} 27. Nd1
{-2.20/9 42} Nd4 {+8.27/10 18} 28. Bxd4 {-2.80/9 24} dxd4 {+10.30/10 26}
29. N@g8 {-2.76/8 12} P@e4 {+8.64/8 23} 30. Ge2 {-3.12/9 24} d3+
{+9.55/8 25} 31. Gexd3 {-3.12/8 8} B@h1 {+8.05/8 39} 32. Rg3 {-4.92/10 16}
P@g4 {+12.11/10 45} 33. Rxg4 {-6.60/10 35} P@d4 {+13.24/10 1:05} 34. Gdc3
{-7.76/9 52} Bxf3+ {+12.76/9 20} 35. Rg3 {-10.08/9 51} +Bxg3 {+16.05/9 34}
36. Nxg3 {-9.00/9 55} R@g2 {+16.05/8 25} 37. Kc1 {-10.36/10 1:07} d3+
{+16.65/9 38} 38. G2xd3 {-7.60/9 24} Rxb3+ {+17.70/9 40} 39. Gxb3
{-7.84/8 16} Rxg3+ {+17.00/8 28} 40. Gbc3 {-8.40/8 19} N@b3 {+18.50/8 51}
41. Kb2 {-9.08/8 33} Nxc3+ {+18.02/8 1:06} 42. Gxc3 {-9.52/8 31} P@d2
{+19.15/7 17} 43. B@c7 {-4.96/8 37} P@b3 {+15.96/7 18} 44. Kxb3
{-2.96/8 18} P@b4 {+15.86/8 30} 45. Kb2 {-3.56/8 15} b3+ {+13.87/8 30} 46.
Kxb3 {-0.88/8 15} P@b4 {+10.26/8 30} 47. Kb2 {-1.96/8 38} G@b3 {+8.92/8 30}
48. Kb1 {-1.16/8 32} B@e7 {+6.71/7 28} 49. Bxg3+ {+1.88/8 13} dxd1+
{+2.56/9 33} 50. +Bc7= {+3.04/8 27} Gf8 {+1.87/8 29} 51. R@h7 {+20.76/8 45}
+Pc1 {-0.27/8 30} 52. Kxc1 {+22.32/8 19} +Be3 {-5.78/8 30} 53. Kb1
{+31.40/8 33} Gb2 {-15.36/8 30} 54. Kxb2 {+0.00/1 0.1} b3+ {-27.63/8 30}
55. Kxb3 {+33.20/7 8} N@a5 {-37.67/8 30} 56. Ka4 {+55.08/8 1:02} Bxa3+
{-54.59/8 20} 57. Kxa3 {+0.00/1 0.1} +Bc1 {-159.88/9 25} 58. Ka2
{+399.72/8 6} +Bb1 {-159.88/8 16} 59. Kxb1 {+399.80/9 0.4} P@b2
{-159.90/7 0.2} 60. Kc1 {+399.84/7} b1+ {-159.92/6 0.1} 61. Kxb1
{+399.84/7 0.2} Bg7 {-159.94/5 0.1} 62. Nxf8+ {+399.88/5 0.1} Kxf8
{-159.96/2 0.1} 63. Rxg7+ {+399.92/3 0.1} Ke8 {-159.98/2 0.1} 64. G@f8#
{+399.96/1 0.1}
{White mates} 1-0
Ok, this is weird: XBoard segfaults when I try to load the PGN. The debug file ends with:

Code: Select all

Parsed game start '[Event "Computer Chess Game"]' (39)
Parsed PGNTag: [Event "Computer Chess Game"]
Parsed PGNTag: [Site "ONTWIKKELLAPTOP"]
Parsed PGNTag: [Date "2015.02.26"]
Parsed PGNTag: [Round "4"]
Parsed PGNTag: [White "Shokidoki euro"]
Parsed PGNTag: [Black "Sjaak II 1.0 RC5"]
Parsed PGNTag: [Result "1-0"]
Parsed PGNTag: [TimeControl "40/1200"]
Parsed PGNTag: [Variant "euroshogi"]
recognized 'euroshogi' (-1) as variant normal
Parsed PGNTag: [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"]
Parsed PGNTag: [FEN "1nbgkgn1/1r4b1/pppppppp/8/8/PPPPPPPP/1B4R1/1NGKGBN1[-] w 0 1"]
shuffleOpenings = 0
FEN castling rights: 90 90 90 90 90 90
Parsed PGNTag: [SetUp "1"]
Parsed Comment: {--------------
. 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
--------------}
Append: in='{--------------
. 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
--------------}' 0
recognized 'Computer Chess Game' (-1) as variant normal
Load Game
and the stack trace (for what it's worth) is

Code: Select all

#0  0x000000010cb6a2be in pngDrawPiece ()
#1  0x000000010cb6ab9e in DrawOneSquare ()
#2  0x000000010cb64b50 in DrawSquare ()
#3  0x000000010cb653e2 in DrawPosition ()
#4  0x000000010cb265e5 in LoadGame ()
#5  0x000000010cb21818 in LoadGameFromFile ()
#6  0x000000010caeaf49 in InitBackEnd3 ()
#7  0x000000010cb8caa8 in FireDelayedEvent ()
#8  0x000000010d03984c in XtAppProcessEvent ()
#9  0x000000010d02fa47 in XtAppMainLoop ()
#10 0x000000010cb89c6b in main ()
myfish
Posts: 131
Joined: Sat Feb 07, 2015 3:17 pm

Re: SjaakII 1.0 RC4

Post by myfish »

hgm wrote:The more I think about it, the more I like this system of non-alphabetic suffixes to single letters for extending the number of piece types in SAN. This causes far less problems than variable-lenth piece IDs made of letters. The large Shogi variants seem the most extreme examples. Their requirement are:

Chu: 21 piece types (+ 18 promoted)
Dai: 29 piece types
Dai Dai: 64 piece types
Maka Dai Dai: 50 piece types
Tai: 93 piece types
Taikyoku: 209 piece types.

When we forget about Taikyoku (which would also pose problems for indicating square coordinates, with its 36x36 board), four times the alphabet would do. Perhaps B, B', B" and B!, when I pick symbols that look narrow in proportional spacing, and are intuitively interpreted as suffixes. Back-quote is mich wider (B`B`B"B"B'B'B!B!B).

The only problem I see is in the FEN tag of a PGN game. PGN tags have syntax [Name "value"], and using double quotes in the 'value' part would cause ambiguous parsing. Especially since FENs can also contain brackets [] for the holdings. If one would have to escape all double quotes in a FEN by preceding them with a backslash, it would lose all its appeal.

But I guess the PGN parser could be made smart enough to treat the FEN tag in a special way, looking for the combination "] to terminate it, after balancing brackets in the FEN. (I.e. the first "] after a [ should not betaken as closure of the tag.

An alternative would be to not use " as suffix at all, (but this would really be a pity, as it is such an obvious choice), or 'escape' them by replacing them with back-quotes only there (and use double quotes in SAN). OTOH, perhaps using back-quotes as one of the possible suffixes can have an advantage of intuitive interpretation: Many of the piece types occurring in these large Shogi variants are the flipped versions of other pieces. Like Gold, Silver or Copper moving backwards. Denoting those by G`, S` or C` would be kind of natural. For laterally symmetric pairs, such as the Tori Quails, Q' and Q" could be natural assignments (where single quotes always indicate 'left', and double quotes 'right'). Exclamation-point suffixes could be reserved for the more important pieces, such as Hook movers (H!, G!, C! for Hook Mover, Goblin and Capricorn), jumping generals in Tenjiku (G!, V!, R!, B! for Great, Vice, Rook and Bishop General), multi-capturers (L!, F! for Lion Dog and Fire Demon).

By having a set of suffixes larger than strictly needed, it would become possible to associate each of them with a certain class of piece types, which would greatly help human interpretation.
This would be great and open the door to all the shogi variants that use a flat board of any size. The limiting factor is going to be our font/piece sizes and screens.

I was trying to find out yesterday how I would configure Wa Shogi and whether there is enough pieces. There are only 17 types not including promotions so I guess we are good to go. A working Tenjiku would be great as there is English documentation to play it. But I never have.