Disambiguation of moves

[hgm]

In changing Winboard for handling fairy pieces I encounter the following conceptual problem for the move parser:

[d] 8/8/8/8/B7/8/BP6/8 w - -

What does 1. b2b3 mean here? Is it a pawn move? Or is it Bb3, (=Ba2-b3) with a 2 as disambiguation character to distinguish it from B4b3 (= Ba4-b2). And what if it is spelled 1. B2B3 ?

With Bishops in FIDE chess such a situation is of course quite unlikely due to the like Bishops, but with fairy pieces and bigger board sizes it can be much more common (e.g. if there exists an n-file, or when you have two Nightriders (H) or Grasshoppers (G)).

[nczempin]

In changing Winboard for handling fairy pieces I encounter the following conceptual problem for the move parser:

[d] 8/8/8/8/B7/8/BP6/8 w - -

What does 1. b2b3 mean here? Is it a pawn move? Or is it Bb3, (=Ba2-b3) with a 2 as disambiguation character to distinguish it from B4b3 (= Ba4-b2). And what if it is spelled 1. B2B3 ?

With Bishops in FIDE chess such a situation is of course quite unlikely due to the like Bishops, but with fairy pieces and bigger board sizes it can be much more common (e.g. if there exists an n-file, or when you have two Nightriders (H) or Grasshoppers (G)).

There is long notation and there is short notation. If you use either of them exclusively, the problem will disappear.

If the two were allowed to be mixed (or it is unknown a priori which is being used), I think the convention is that piece designations are in capital letters, while file designations are lowercase.

[hgm]

OK, thanks for the input.

The problem is that the current Winboard parser seems to recognize both upper and lower case for the piece-type designator. I can easily change that to recognize upper case only, but 'd rather not do that, as whole groups of engines that work under Winboard now, might cease to work with it if they happened to use lower case.

I guess the best solution is to make the parser prefer the long notation if there is indeed a Pawn on the thus derived FromSquare, as two like Bishops are extremely unlikely. And in FIDE Chess the B is the only case that can designate both piece and file. For fairy pieces I will simply require a capital.

[nczempin]

OK, thanks for the input.

The problem is that the current Winboard parser seems to recognize both upper and lower case for the piece-type designator. I can easily change that to recognize upper case only, but 'd rather not do that, as whole groups of engines that work under Winboard now, might cease to work with it if they happened to use lower case.

I guess the best solution is to make the parser prefer the long notation if there is indeed a Pawn on the thus derived FromSquare, as two like Bishops are extremely unlikely. And in FIDE Chess the B is the only case that can designate both piece and file. For fairy pieces I will simply require a capital.

Oh, you're talking about Winboard (the program, not the specification)! Then all bets are off...

The WB spec says this:

move MOVE
Your engine is making the move MOVE. Do not echo moves from xboard with this command; send only new moves made by the engine.

For the actual move text from your chess engine (in place of MOVE above), your move should be either

* in coordinate notation (e.g., e2e4, e7e8q) with castling indicated by the King's two-square move (e.g., e1g1), or
* in Standard Algebraic Notation (SAN) as defined in the Portable Game Notation standard (e.g, e4, Nf3, O-O, cxb5, Nxe4, e8=Q), with the extension piece@square (e.g., P@f7) to handle piece placement in bughouse and crazyhouse.

xboard itself also accepts some variants of SAN, but for compatibility with non-xboard interfaces, it is best not to rely on this behavior.

and that PGN standard says this:

SAN identifies each of the sixty four squares on the chessboard with a unique two character name. The first character of a square identifier is the file of the square; a file is a column of eight squares designated by a single lower case letter from "a" (leftmost or queenside) up to and including "h" (rightmost or kingside). The second character of a square identifier is the rank of the square; a rank is a row of eight squares designated by a single digit from "1" (bottom side [White's first rank]) up to and including "8" (top side [Black's first rank]). The initial squares of some pieces are: white queen rook at a1, white king at e1, black queen knight pawn at b7, and black king rook at h8. SAN identifies each piece by a single upper case letter. The standard English values: pawn = "P", knight = "N", bishop = "B", rook = "R", queen = "Q", and king = "K".

[hgm]

OK, thanks. The standard is clear: piece designator should be upper case, file indicator lower case.

I was surprised to see that the original Winboard parser also allows lower case for the piece designators. (File must be lower case, though).

The 'b'-problem is bearable, and the next possible problem, a board with an n-file, is not likely to be needed. So if I require tight standards for the new pieces, no new problems can arise, and there is no need to clamp down on any existing violations of the standard.

[Alex Brunetti]

With Bishops in FIDE chess such a situation is of course quite unlikely due to the like Bishops

There's a much more common situation (I encountered it a few days ago): bxc5 and Bxc5 (or any other square a2-a7 and c2-c7). It could be a problem for engines that accept SAN notation and ignore the case, like mine. I think I won't give up the case ignoring, but just consider the case whenever there's such an ambiguity, treating it as a special case. Obviously the cost is negligible.

Alex

[nczempin]

With Bishops in FIDE chess such a situation is of course quite unlikely due to the like Bishops

There's a much more common situation (I encountered it a few days ago): bxc5 and Bxc5 (or any other square a2-a7 and c2-c7). It could be a problem for engines that accept SAN notation and ignore the case, like mine. I think I won't give up the case ignoring, but just consider the case whenever there's such an ambiguity, treating it as a special case. Obviously the cost is negligible.

Alex

I think we should all go back to the NxQRP notation of ye olde days. Boy, I have a copy of "Think Like A Grandmaster" in descriptive. Totally unreadable.

[bob]

In changing Winboard for handling fairy pieces I encounter the following conceptual problem for the move parser:

[d] 8/8/8/8/B7/8/BP6/8 w - -

What does 1. b2b3 mean here? Is it a pawn move? Or is it Bb3, (=Ba2-b3) with a 2 as disambiguation character to distinguish it from B4b3 (= Ba4-b2). And what if it is spelled 1. B2B3 ?

With Bishops in FIDE chess such a situation is of course quite unlikely due to the like Bishops, but with fairy pieces and bigger board sizes it can be much more common (e.g. if there exists an n-file, or when you have two Nightriders (H) or Grasshoppers (G)).

What I have always done is to report that as ambiguous, and make the operator type something less so. Bb3 can't be confused. Second, I would _never_ use b2b3 anyway for pawn pushes and would only type b3 which can not be a bishop move using SAN.

In normal chess language, b2b3 would therefore mean to move the bishop on the 2nd rank to b3. It can't be confused with a pawn push because pawn pushes are two letter moves only unless they are promotions.

In Crafty, to facilitate fast typing, I accept b3 and would give an error for being ambiguous, because two bishops can move to the 3rd rank along with one pawn. B3 is still ambiguous since two B's can reach the 3rd rank. But then again SAN doesn't allow B3 as a move either, as the destination square is always specified as a two-character pair...

[bob]

OK, thanks for the input.

The problem is that the current Winboard parser seems to recognize both upper and lower case for the piece-type designator. I can easily change that to recognize upper case only, but 'd rather not do that, as whole groups of engines that work under Winboard now, might cease to work with it if they happened to use lower case.

I guess the best solution is to make the parser prefer the long notation if there is indeed a Pawn on the thus derived FromSquare, as two like Bishops are extremely unlikely. And in FIDE Chess the B is the only case that can designate both piece and file. For fairy pieces I will simply require a capital.

Just use SAN, and b3 can't possibly be a bishop move because the minimal san is PXX where P is the piece type, XX is the destination square. SAN was defined carefully to avoid this kind of problem.

[bob]

With Bishops in FIDE chess such a situation is of course quite unlikely due to the like Bishops

There's a much more common situation (I encountered it a few days ago): bxc5 and Bxc5 (or any other square a2-a7 and c2-c7). It could be a problem for engines that accept SAN notation and ignore the case, like mine. I think I won't give up the case ignoring, but just consider the case whenever there's such an ambiguity, treating it as a special case. Obviously the cost is negligible.

Alex

I ignore case in Crafty, and would then call that move ambiguous and make you type Bxc5 if you want to capture with the bishop, or bxc5 if you want to capture with the pawn. SAN only allows caps for pieces, but I allow lower case to make typing go faster in blitz games when I run from a dumb terminal window.