Seirawan Chess at my ICS

[Evert]

Gating moves are written as promotions. (There never is any ambiguity, as Pawns are not allowed to gate, and even if they would, a virgin Pawn cannot promote.) So you would write f1g3e to gate the Elephant at f1. In SAN WinBoard now accepts both = and / in gatings and true promotions, and writes = with promotions and / with gatings. The ICS writes = for both, however.

Two related questions:
1. When castling, you can gate one piece to either the original square of the king, or the original square of the rook (from Wikipedia). How do you specify which one it is? Plain "e1g1h" is ambiguous.
2. How do you do this in the GUI? I know to select the piece from holdings before the move, but how do I get it to go to the rook's square when castling?

EDIT: ah, I see you posted that information while I was typing this. Good.

This info seems to make the castling field superfluous, and could perhaps replace it.

That seems reasonable.

Reinhard proposed two hex numbers separated by a period, representing a bitmap of the virgin pieces, like

rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR [HEhe] w FF.FF - 0 1

I am not so keen to use hexadecimal in FEN, though.

Ditto.
The strength of FEN is that it is easily readable for humans, and this would be lost by including hexadecimal numbers. Plus, it wouldn't generalise to variants on a large board that include gating.

A alternative would be to append the file letters of non-virgin pieces still in their original position to the castling field. (In practice there are never many of those).

This is a generalisation of the FRC FEN castling flags, and makes sense to me. I think this is the best option.
(But maybe I'm biased because this is what Sjaak does internally anyway)

Another, more general issue is if it is really desirable to use H and E for pieces that in other variants are called A and C.

Consistency (with respect to other variants implemented now as well as other variants that may be added in the future) is the important question here, I think. Either is fine, as long as it's clear.
Perhaps consistency with XBoard is the most obvious choice.

Unrelated question: are you planning a Seirawan tournament at some point in the future?
I ask, because if so there are some changes I need to make to Sjaak (straightforward changes, but still); it currently can't store castle+gate moves.

[hgm]

This is a generalisation of the FRC FEN castling flags, and makes sense to me. I think this is the best option.

Well, it would do the reverse of FRC castlings. Otherwise you would have to write ABCDEFGHabcdefgh in the initial position...

[Evert]

This is a generalisation of the FRC FEN castling flags, and makes sense to me. I think this is the best option.

Well, it would do the reverse of FRC castlings.

Oh, I don't think that is a good idea. Some uniformity between FEN strings for variants is desirable, otherwise it becomes a confusing mess.

Otherwise you would have to write ABCDEFGHabcdefgh in the initial position...

Yes, but other than being excessively verbose, that's not a real problem. Note that FEN strings of positions further along in the game become simpler, so the problem goes away by itself. To simplify things further, you can suppress the information once both pieces have been gated in.

[hgm]

True, but there still would be a potentially confusing matter that the conventional castling field would specify only virgin Rooks,and ignore the King. So AHah would imply castling rights in Chess960, while is would specify no castling rights in Seirawan Chess, because the King has moved, but only gating rights at both Rooks.

An advantage, though, is that is would be fully compatible with shuffle forms of Seirawan Chess.

Reinhard suggested to adopt the convention that the gating rights should only be written when they are still relevant. (He interprets this field as an 'extra possibilities field', rather than virginity field per se.) This would ensure convergence to standard FEN later in the game, when all pieces have been gated. To fully acheive that, we would have to specify that mentioning a Rook without pieces in hand implies virginity of the King, as it can only mean the Rook can castle. KQkq of course apply to (outer) Rook and King both, as usual. So for the initial position of Seirawan Chess we could write KQBCDFGkqbcdfg in the castling field, to save 2 characters.

Unrelated question: are you planning a Seirawan tournament at some point in the future?
I ask, because if so there are some changes I need to make to Sjaak (straightforward changes, but still); it currently can't store castle+gate moves.

If there are at least 4 engines (and it seems there could be) I will certainly do a tourney at some point. I would have to adapt the ChessLive! viewer system to handle holdings / drops /gatings, though.

[smrf]

As there has been in an example of Chess960, there is no chance to have a universial form of castling rights / special ability flags. But this it is highly recommended to have a clear distinction between those two views.

Thus I vote for a separating dot '.' to create a unique interpratation of having position bound individual flags (which is not used in Chess960 or traditional Chess for the King's castling rights, but it might depend of a view to have the castling rights locate merely at the rooks and beeing still cleared when the king is moving).

To use hex numbers would have two advantages: it is short and could be nicer extended to bigger boards. It must not be always exactly two hex digits, it will shrink finally to "0.0" or more simple to "." or "-" as done more traditional.

An explicite listing of column letters as "abcdefgh.ABCDEFGH" will increase to still more oversize at bigger boards, and it is suggesting, that the order of the letters are of importance, which is not the case.

In XFEN I will soon try to also include free castling. This will also use the fifth position of the algebraic notation to solve ambiguities. Here there also is the problem to distinguish where to place a piece when castling. I vote against a reverting of source and destination coordinate or to use the one of the rook. Instead I suggest to use the normal lower letter for to address the freed field by the normally moving king and to use a capital letter for the rook's one.

[hgm]

An explicite listing of column letters as "abcdefgh.ABCDEFGH" will increase to still more oversize at bigger boards, and it is suggesting, that the order of the letters are of importance, which is not the case.

Is length really a problem? If we have to choose between clarity and compactness, I tend to agree with Evert we should go for clarity.

If, for argument's sake, we assume we would specify the virgin pieces with their file letter, why would you still want the dot? This format is fully upward compatible with Shredder FEN, so there is no need to have an independent way to see if it is a conventional castling field, or a more general extended-abilities field. That simply follows from what is listed in it. Conventional castling-rights fields do not list virginity of non-King, non-Rook pieces, because this is not relevant. As soon as it becomes relevant, such as for gating when there are pieces in hand, it would be natural to list those as well. An explicit distinctive trait would only be needed if the letters meant something different than in a conventional castling field (like non-virginity rather than virginity).

If you allow the use of KQkq in its usual meaning (=virginity of King and outer Rook), it would even be upward compatible with X-FEN.

[edit:] After posting this I saw you posted in WB forum that you sort of agree with this.

In XFEN I will soon try to also include free castling. This will also use the fifth position of the algebraic notation to solve ambiguities. Here there also is the problem to distinguish where to place a piece when castling.

Why not indicate free castling as a general (comma-separated) double move, like Ke1-b1,Ra1-d1 (or Kb1,Rad1 for short). There are other Chess variants that allow multiple moves per turn

I vote against a reverting of source and destination coordinate or to use the one of the rook. Instead I suggest to use the normal lower letter for to address the freed field by the normally moving king and to use a capital letter for the rook's one.

Well, the official way in Seirawan Chess is to include the full square behind the gated piece ID. This is not very SAN-like, however. I agree that Rxe1/H is ugly, and we should find something better for it. Using coordinates (like Ke1-g1) is not standard SAN anyway, and incompatible with Chess960. It is used in the protocol notation only, which is of no concern to anyone except for the protocol designer. The logical solution in SAN would be to include a file-disambiguator, like O-O-O/Ea when you gate at the Rook square, O-O/He when you gate at the King square. As the use of a slash is already a SAN extension, it would be a small step to define another suffix character for the Rook-square gatings, like backslash. E.g. O-O/H gates a Hawk on e1, while O-O\H gates it at h1.

[Evert]

Why not indicate free castling as a general (comma-separated) double move, like Ke1-b1,Ra1-d1 (or Kb1,Rad1 for short). There are other Chess variants that allow multiple moves per turn

In fact, why not send gating as a double move: "f1c4,E@f1" for instance or, indeed, "O-O,E@h1"?
Actually, independent of whatever other way of entering gating moves is available, does it do the correct thing if I send a gating move that way? It would allow for more general code.

[hgm]

In fact, why not send gating as a double move: "f1c4,E@f1" for instance or, indeed, "O-O,E@h1"?

Mainly because the /H or /E notation already seemed to be commonly used.

Actually, independent of whatever other way of entering gating moves is available, does it do the correct thing if I send a gating move that way? It would allow for more general code.

It would only work in variants multimove and higher (checkers, alien), and thus only in the Alien Edition (as the standard version does not support these variants). It would be quite easy to allow it (in the Alien Edition) in other cases. (e.g. it could give an entirely new meaning to variant wildcastle!).

[Evert]

It would only work in variants multimove and higher (checkers, alien), and thus only in the Alien Edition (as the standard version does not support these variants). It would be quite easy to allow it (in the Alien Edition) in other cases. (e.g. it could give an entirely new meaning to variant wildcastle!).

Do you plan to merge these different versions again at some point?

[George Tsavdaris]

I am working now together with Yasser Seirawan to get the variant he and Bruce Harper invented (also known as S-Chess) running on the open-source ICS code. I have set up the Fairy-Max bot on my ICS to now also take challenges in variant seirawan.

Those interested are invited to give it a try, either by playing each other, or playing the Fairy-Max bot. To start an S-Chess game when logged on to the ICS, you can use the command:

match FairyMax 5 1 sc

(the sc here means S-Chess = variant seirawan; gc would be variant gothic, km would be knightmate, su would be SuperChess = variant super. 5 1 means 5min +1 sec/move, as usual, and in stead of FairyMax you could of course type the name of another opponent).

To connect to the ICS you can use the command

winboard -ics -icshost 80.100.28.169 -icshelper timeseal

Hmm you are full of surprises...

I didn't know that. It is always nice to have a spare partner whenever you want to play some Gothic Chess for example....

I didn't manage to find a human unfortunately, i didn't even know how to search for one( i will read all the stuff tomorrow), but i played 2 games with FairyMax. Why you don't put other stronger engines there too?

2 easy wins for the old lion.

[Event "ICS unrated gothic match"]
[Site "80.100.28.169"]
[Date "2011.12.29"]
[Round "-"]
[White "mtalriga"]
[Black "FairyMax"]
[Result "1-0"]
[WhiteElo "0"]
[BlackElo "1293"]
[TimeControl "600+1"]
[Variant "gothic"]

1. f4 d5 2. d4 Nc6 3. c3 Be6 4. h3 Nh6 5. Be3 Nf5 6. Bf2 Cd6 7. g3 Cb5 8.
Qc1 Qd6 9. e3 O-O-O 10. b4 a5 11. a4 Cb6 12. b5 Nb8 13. Nd2 c6 14. e4 dxe4
15. Bxe4 Ca8 16. Cc2 Nd7 17. Af3 Kc7 18. c4 Nf8 19. c5 Qd7 20. Ae5+ Nd6 21.
bxc6 Bc4+ 22. Cxc4 Kb8 23. Qb2 Qc7 24. Rb1 f6 25. cxd6 Axc4+ 26. Nxc4 Rxd6
27. Qxb7+ Qxb7 28. Rxb7+ Kc8 29. Nxd6+ exd6 30. Bf5+ Nd7 31. Axd6+ Kd8 32.
Rxd7#
{FairyMax checkmated} 1-0

[Event "ICS unrated gothic match"]
[Site "80.100.28.169"]
[Date "2011.12.29"]
[Round "-"]
[White "FairyMax"]
[Black "mtalriga"]
[Result "0-1"]
[WhiteElo "1293"]
[BlackElo "0"]
[TimeControl "600+1"]
[Variant "gothic"]

1. d3 d5 2. Nd2 h6 3. e4 c6 4. Nh3 g6 5. g3 e6 6. Bf3 i6 7. c4 dxc4 8. Nxc4
Nj6 9. Bf4 e5 10. Be3 Na6 11. Qd2 Bg7 12. Cc2 Ai7 13. O-O-O O-O 14. Be2 Nc7
15. f4 exf4 16. Bxf4 Nb5 17. Be3 Be6 18. a4 Nd6 19. Nxd6 Cxd6 20. Ca1 b6
21. Nf4 Bd7 22. Bf3 Rc8 23. a5 c5 24. a6 f6 25. Nh3 Cb5 26. Ae2 Ag8 27. Kc2
Qe7 28. Nf4 Qf7 29. Ag1 Qa2 30. Cxa2 Axa2 31. Qe1 c4 32. d4 c3 33. Rb1 Ab3+
34. Kd3 Ac4+ 35. Kc2 Cb4+ 36. Kd1 c2+ 37. Kc1 Ab3#
{FairyMax checkmated} 0-1