WB reports illegal moves when playing variant: Seirawan

[iqp]

Hi,

despite nobody playing it anymore I've recently become interested in Seirawan Chess or S-Chess & was delighted to find out that it can be played on WinBoard, thanks to Fairy-Max (I already use WinBoard to play Minishogi).

I've tried playing a few engine games and every time, without fail, I receive an error "illegal move "xxyy" from first machine". Here is the link to the PGN records and WB debug logs on Dropbox (I couldn't figure out how to attach files to this post) from two games if anyone is willing to help investigate. In the first game WinBoard complained about the move b8d7 and g8h6 in the second. What I suspect is happening is that fmax is not including its elephant/falcon drops in its output or perhaps WinBoard is not looking for that information in the engine output. Either way, WinBoard didn't display an elephant or falcon on b8 or g8 in the first and second games respectively.

Kind Regards,
Ralph

[Reinhard Scharnagl]

An additional question: how should the XFEN for Seirawan be?
That is how to document the still being placable pieces?

[iqp]

An additional question: how should the XFEN for Seirawan be?
That is how to document the still being placable pieces?

AFAIK this is already taken care of. After starting a new game of S-Chess in WB and copying the position I get:

Code: Select all

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

Notice the HEhe representing respectively white and black's hawk and elephant still being placeable.

The X-FEN after the opening moves 1.Nf3/H d5 2.Nc3/E Nc6 is:

Code: Select all

r1bqkbnr/ppp1pppp/2n5/3p4/8/2N2N2/PPPPPPPP/REBQKBHR[he] w KQkgfdcq - 2 3

showing that only black is still able to place hawk and elephant.

[Reinhard Scharnagl]

Well I see, but XFEN has to translate H -> A and E -> C to stay consistent.
Moreover I do not at all understand the strange castling information string.

P.S. well, when the brackets [] always remain parts of the XFEN, even when
empty, such a translation may be done implicit, and the ability to promote
into such pieces also will be induced by their existence.

But concerning the castling flags, there seems to be a misuse of them. The
possible occurrence of letters is already used by random chess variants.

P.P.S. Maybe there is a better solution for that. I propose following: if there
are still placable pieces within the brackets, place an additional number
in front of the pieces of one color, which is built from all moved pieces
in the front array by adding affected column numbers 1-2-4-8-16-32-64-128.
As most pieces have been moved forward, so no number at all will be needed.

[H.G.Muller]

IIRC the idea was to make the castling field into a general virginity field. Castling rights follow from virginity information of the King and Rooks. For backward compatibility rights that have no meaning are not written (i.e. when there are no pieces in hand anymore only the Rook virginities are written, and then only if the King is still virgin). As usual K and Q can be taken to mean outer Rook + King virginity, and suppress explicit mentioning of the files of these. E.g. KGFDCBQ for the standard opening position. E would then have to appear only as soon as both Rooks were moved.

I don't think using binary notation would make the FEN understandable by the average human reader. You might as well encode the whole board in binary Hufman code then...

[iqp]

Hi Mr Muller,

please could you help me figure out why WB is complaining about illegal moves when playing the Seirawan variant as described in the OP?

TIA,
Ralph

[Reinhard Scharnagl]

... I don't think using binary notation would make the FEN understandable by the average human reader. You might as well encode the whole board in binary Hufman code then...

Well, I have no intention to pollute the XFEN approach by incompatible overloading of the castling string.
Because it seems to be impossible then e.g. to implement a thing like Random Seiravan Chess. My suggestion
in contrast will have a mostly nearly clean XFEN encoding instead of an unreadable castling string.

An alternative could be to precede the still placable pieces by those letters of columns having moved pieces,
but this would imply to use distinct piece letters, instead of E and H, or e.g. to supply two [] bracket pairs for
white and black each and then always use capital piece letters preceded by lower case column letters
having moved own pieces standing at the starting array, as long as there are placable pieces.

P.S.:
1) is a just placed H or E always an unmoved piece then?
2) such a placement is changing the material balance, so why this does not reset the remis count?

P.P.S.: Finally I suggest to use L for Elephant and W for Hawk (maybe within the brackets only), this
would give the chance to use a single [] bracket pair only.

[H.G.Muller]

Well, I have no intention to pollute the XFEN approach by incompatible overloading of the castling string.
Because it seems to be impossible then e.g. to implement a thing like Random Seiravan Chess. My suggestion
in contrast will have a mostly nearly clean XFEN encoding instead of an unreadable castling string.

Why do you say that? The current system was designed with Seirawan2880 in mind. There is nothing incompatible with the XFEN castling field; it is a straightforward extension of it. In stead of mentioning only virgin Rooks, you measure all virgin pieces. What could be more straightforward than that?

As I see it your proposal trades an 'unreadable' castling string for an even (far) more unreadable holdings field. One would have to convert a decimal number to binary before one could know which pieces are virgin! It would be about 10,000 times easier to write it in binary in the first place, but even that would be highly inferior, because you would have to count stretches of 0s to know to which file a certain 1 corresponds. Much easier to write a letter identifying the file than always writing a 1. Then you could drop the zeros completely.

If writing is between the brackets would cause confusion between files and pieces, it is just stupid to write it there. Because you can write it anywhere you want, and there are many places in which it would not cause any confusion at all. But the point is that when you write this information in a separate field, it makes the castling field totally redundant. If you know whether you can gate at the Rook and King files, you also know that you can castle with that Rook...

1) is a just placed H or E always an unmoved piece then?

No, you cannot gate a second time on the same square.

2) such a placement is changing the material balance, so why this does not reset the remis count?

The 50-move counter is reset on making progress towards a win. Gaining material or simplifying often is, as are Pawn pushes, which bring you closer to promotion. Transfering a piece from the hand to the board is not bringing you any closer to victory. There was never any question you would sooner or later do that. It doesn't really change the material balance, as the hand should be included in the material count (as long as you still have enough virgin pieces). The fact that it is an irreversible move is not in itself reason for resetting the counter; compare castling, which also irrecversibly loses you the right to do it.

P.P.S.: Finally I suggest to use L for Elephant and W for Hawk (maybe within the brackets only), this
would give the chance to use a single [] bracket pair only.

Why so obsessed with the number of bracker pairs? Who cares whether there is a single pair, or two, or whether you write the virginity between {braces}, or within the brackets separated by colons from the pieces (e.g. [whitevirginity:Pieces:blackvirginity]. There are zillions of possibilities to do this that do not require using unnatural letters to abbreviate the piece names.

I consider the redundancy problem of having one field that completely implies another field much more serious than the interpunction you would use to distinguis these pieces of info from each other...

[H.G.Muller]

Hi Mr Muller,

please could you help me figure out why WB is complaining about illegal moves when playing the Seirawan variant as described in the OP?

TIA,
Ralph

Yes, I will, but you did not post the debug file, so I have to try it out myself first.

It seems that Fairy-Max is broken. It sends WinBoard the move g8f6` when it actually means g8f6h (i.e. gating a Hawk), and WinBoard's move parser of course ignores the back-quote, so that when Fairy-Max then tries to move the Hawk from g8 on the next move, WinBoard considers it an illegal move.

So there seems to be a problem with printing the gating moves in Fairy-Max, picking a wrong character for encoding the gated piece. I am not sure how that could have crept in; originally (immediately after I implemented Seirawan) it was working, so I must have broken it at some point. I will try to fix it tomorrow. Thank you for reporting this.

[iqp]

Hi Mr Muller,

please could you help me figure out why WB is complaining about illegal moves when playing the Seirawan variant as described in the OP?

TIA,
Ralph

Yes, I will, but you did not post the debug file, so I have to try it out myself first.

Thank you. I couldn't figure out how to attach files to my forum post but I did include a Dropbox link to the debug files in my original message. Here is is again: https://www.dropbox.com/s/nvf1zwdw8zzvb ... or.7z?dl=0

[H.G.Muller]

Oh sorry, I overlooked that link.

Anyway, the error slipped in when I did overhaul Fairy-Max' promotion code, so that it would accurately keep score when the user under-promoted, rather than just assuming this would earn him a Queen, and to allow black to have a different default promotion piece as white. At that time I forgot to strip off the virginity and color bits of the piece code for the gated piece, when feeding it to the code to print the promotion suffix, with as a result that garbage was printed.

It should be fixed now; the repaired Fairy-Max can be downloaded from

http://hgm.nubati.net/Fairy-Max.zip

Just unpack it over your old Fairy-Max folder. (Only the fmax.exe and fmax.ini files are new, really.)

[iqp]

Oh sorry, I overlooked that link.
It should be fixed now; the repaired Fairy-Max can be downloaded from

http://hgm.nubati.net/Fairy-Max.zip

Just unpack it over your old Fairy-Max folder. (Only the fmax.exe and fmax.ini files are new, really.)

Wonderful, it works now. Thank you very much!

[Reinhard Scharnagl]

Well, I have no intention to pollute the XFEN approach by incompatible overloading of the castling string.
Because it seems to be impossible then e.g. to implement a thing like Random Seiravan Chess. My suggestion
in contrast will have a mostly nearly clean XFEN encoding instead of an unreadable castling string.

Why do you say that? The current system was designed with Seirawan2880 in mind. There is nothing incompatible with the XFEN castling field; it is a straightforward extension of it. In stead of mentioning only virgin Rooks, you measure all virgin pieces. What could be more straightforward than that?
...

You are presuming, that an unmoved rook always will have castling rights. There are cases with two rooks at one side, where a letter is used to select the inner rook for castling rights. Here you are mixing that up with its unmoved property. So there you are unable to encode a missing castling ability. But I confess, that this are very rare cases. In the commercial Chess960 Shredder-FEN in contrast this would be a regular difficulty. The bigger problem is also then, when a king has been moved and all castling rights are lost, though the rooks will remain unmoved.

That would lead to following, using [] brackets should skip any QKqk usage in the castling string, but instead only use upper/lower case letters for all unmoved pieces in the starting array. That would be a clear alternative. And additionally it would imply (as your current approach, too) that Seiravan Chess could not be combined with any nocastle variant.

[H.G.Muller]

You are presuming, that an unmoved rook always will have castling rights. There are cases with two rooks at one side, where a letter is used to select the inner rook for castling rights. Here you are mixing that up with its unmoved property.

You mean that when the (inner) Rook has not moved it gets a letter E (say), despite the fact that it might not have castling rights because the King has moved? But that should not be a problem, because it will also be explicitly shown whether the King has moved.

So there you are unable to encode a missing castling ability.

The fool-proof decoding algorithm is this:

Pieces in hand? Castling if and only if Rook and King file both mentioned, otherwise mentioned files only have gating rights
No pieces in hand? Castling if and only if Rook file mentioned

As for constructing the FEN, there is the rule that virginity of pieces is not mentioned in cases where it makes no difference, with the understanding that castling rights are only mentioned through the Rooks. (A logical choice, as mentioning the King would not tell you which castling(s) it can do, while mentioning them on both would be redundant and create a possibility for inconsistency. A Rook, on the other hand, can only be involved in a single castling, as there is only one King.) So:

Pieces in Hand? Mention the file of all back-rank pieces that have not moved
No pieces in hand and King not moved? Mention all files with unmoved Rooks
No pieces in hand and King has moved? Mention nothing

[Reinhard Scharnagl]

Well, HGM, also because of your remarks there is no need to use KkQq inside the list of letters of unmoved
pieces, moreover because KkQq complex letters regularly are representing two unmoved pieces.
Avoiding would underline the different meaning of "castling"-string elements there as an "unmoved"-string.
And it would imply that as for Seirawan chess nocastling never could be an option.

P.S.: Instead of encoding up to 16 unmoved letters it seems to be more efficient to encode the moved
baseline pieces letters, which will mostly remain an empty set, because pieces regularly will be moved
towards the center. This could be done e.g. color separated as [aEH:cdEH], having still the XFEN castling
encoding.

[H.G.Muller]

Not allowing castling despite the fact that King and Rook have not moved would definitely be a rule change. In general it is not possible to encode the full rules of the game in the FEN. Allowing pieces in hand to be gated by non-virgin pieces that revisit the back-rank, or even just anywhere, would be another rule change that you could not see from the FEN. Or that you would lose castling rights by being checked.

I would not worry about all that. A FEN should be designed to describe the game state of a game with a specific set of rules. Not for other games played according to how the rules might have been.

You are right that KQkq are redundant. They are even redundant in FRC/CRC, and only of interest for backward compatibility with FIDE FENs there. But as long as there are pieces in hand, there never is compatibility between Seirawan and FIDE/FRC, so I guess this is no issue here. But because with empty hands K means outer-right Rook + King and Q means outer-left Rook + King, I saw no reason to forbid that it means the same with pieces in hand.

One could argue that there is a certain convenience in using K & Q, as in general it highlights the castling rights within the virginity field. For a Seirawan2880 game I would only have to look at the virginity field to immediately see who can still castle, and towards which wing. Just summing up the files would not tell me that without looking at the board first to see where the Rooks are, and then scanning through all the letters to see if those of the Rook files are present. The idea was to have K always be mentioned first, and Q always last, irrespective of which files the Rooks are on, so that they stick out even more. That it doesn't always work, because another Rook might move beyond the original one, is too bad, but IMO no reason to not do it when it is possible.

I agree that mentioning moved baseline pieces rather than virgin ones in general gives less cluttered notation. But it we decided against it because it was not compatible with the conventional way castling rights are written. Finally we decided that saving 2x5 extra letters there was not worth it to formulate complex rules, especially since (as you say) pieces don't tend to linger on the base line. Eight moves into the game the Knights and one Bishop are likely to have already been developed, so we would be talking of only 2x2 extra letters then. We didn't think that was worth much of a fuss. Only the initial position looks exceptionally ugly, because everything is still virgin.

[iqp]

Hi Mr Muller,

I just want to say thank you again for fixing Fairy-Max so that it works with the Seirawan Chess variant! It's a little OT but I wanted to post a game that I played today. It won't win any brilliancy prizes but I thought this game showed the powers of hawk and elephant quite nicely, especially the mate.

Below is a diagram of the final position followed by the PGN:

Code: Select all

[Event "Computer Chess Game"]
[Site "MORITZ-PC"]
[Date "2014.10.16"]
[Round "-"]
[White "ralph_000"]
[Black "Fairy-Max 4.8T"]
[Result "0-1"]
[TimeControl "40/300"]
[Variant "seirawan"]
[Annotator "1... +0.25"]

1. e4 Nc6/E {+0.25/7 32} 2. Ne2/H f5 {+0.06/7 6} 3. Nbc3/E fxe4 {+0.16/7 4}
4. Nxe4 Nf6/H {+0.24/8 4} 5. d3 Nxe4 {+0.17/9 5} 6. dxe4 Hf6 {+0.04/8 5} 7.
Ng3 e6 {-0.09/7 5} 8. Bb5 Bb4+ {+0.01/7 11} 9. Bd2 Bxd2+ {+0.19/8 9} 10.
Qxd2 O-O {+0.10/8 14} 11. He2 a6 {+0.05/9 7} 12. Bxc6 bxc6 {+0.22/9 7} 13.
b4 d5 {+0.13/7 4} 14. O-O dxe4 {+0.85/9 5} 15. Qxd8 Rxd8 {+1.06/9 9} 16.
Rd1 Rxd1+ {+1.12/10 5} 17. Hxd1 Bd7 {+1.05/9 4} 18. c3 Eb5 {+1.04/9 6} 19.
Ed2 Ed6 {+1.02/9 5} 20. Eb3 Ed3 {+1.05/7 4} 21. a4 Ee1+ {+2.58/10 5} 22.
Nf1 Hh4 {+2.93/11 12} 23. He3 Ee2+ {+12.28/12 5} 24. Kh1 Exe3 {+12.27/12 4}
25. fxe3 Hf2# {+79.99/28}
{Xboard adjudication: Checkmate} 0-1