En passant square in FEN (in UCI)

[UncombedCoconut]

IMHO the assert was appropriate, because it caught a bug in stockfish. That's what assertions are for! I guess I was unclear about where the assert fired: it's when the movegen saw a recorded e.p. square in stockfish's internal data structure that shouldn't be there (and makes it hash to the wrong value). Maybe it sounds less evil now?

Thanks for the info about Winboard+Polyglot. (At least I think you mean with Polyglot, as Stockfish speaks UCI?) The UCI spec doesn't seem to define FEN, so I think the best definition is "whatever mainstream UCI GUIs send as FEN"!

[mcostalba]

Sorry, this is obviously wrong (uploaded a crazy test); it should be:

Thanks Justin, following patch has been applied:

Code: Select all

Date: Wed, 6 Jan 2010 09:58:41 +0100
Subject: [PATCH] Fix en-passant parsing from fen string

According to standard en-passant is recorded in fen string regardless
of whether there is a pawn in position to make an en passant capture.

Instead internally we set ep square only if the pawn can be captured.
So teach from_fen() to correctly handle this difference.

Bug reported and fixed by Justin Blanchard.

No functional change.

---
 src/position.cpp |   10 +++++++---
 1 files changed, 7 insertions(+), 3 deletions(-)

diff --git a/src/position.cpp b/src/position.cpp
index b4ccff5..266b18d 100644
--- a/src/position.cpp
+++ b/src/position.cpp
@@ -204,12 +204,16 @@ void Position::from_fen(const string& fen) {
   while (fen[i] == ' ')
       i++;
 
-  // En passant square
+  // En passant square -- ignore if no capture is possible
   if (    i <= fen.length() - 2
       && (fen[i] >= 'a' && fen[i] <= 'h')
       && (fen[i+1] == '3' || fen[i+1] == '6'))
-      st->epSquare = square_from_string(fen.substr(i, 2));
-
+  {
+      Square fenEpSquare = square_from_string(fen.substr(i, 2));
+      Color them = opposite_color(sideToMove);
+      if (attacks_from<PAWN>(fenEpSquare, them) & this->pieces(PAWN, sideToMove))
+          st->epSquare = square_from_string(fen.substr(i, 2));
+  }
   // Various initialisation
   for (Square sq = SQ_A1; sq <= SQ_H8; sq++)
       castleRightsMask[sq] = ALL_CASTLES;
-- 
1.6.4.msysgit.0

As you see there is a little difference from yours, namely

Code: Select all

attacks_from<PAWN>(fenEpSquare, them)

instead of

attacks_from<PAWN>(fenEpSquare)

Otherwise the patch fails with the following test string

Code: Select all

FEN = 8/K1P4k/8/3p4/8/8/8/8 w - d6 0 20

Thanks again for your report and patch !

Marco

[smrf]

... XFEN is apparently not upward compatible with FENs for normal Chess as defined by the PGN standard... :lol:

PGN does not state any FEN standard for variants. Thus it is only important, whether FEN extensions are compatible to notations of traditional chess positions.

XFEN is fully downward compatible to FEN whereas Shredder FEN is producing different notations for positions which could either be interpreted as coming from Chess960 or from traditional Chess.

[Sven]

Code: Select all

// En passant square -- ignore if no capture is possible

Maybe the comment should be slightly improved like:

Code: Select all

// En passant square -- ignore if no pseudo-legal capture is possible

since pins preventing a pseudo-legal ep capture are not evaluated.

Sven

[hgm]

XFEN is fully downward compatible to FEN whereas Shredder FEN is producing different notations for positions which could either be interpreted as coming from Chess960 or from traditional Chess.

Let me make sure I understand this. So in XFEN the position after 1.e4 will be written as

rnbqkbnr/pppppppp/8/8/4P3/8/PPPP1PPP/RNBQKBNR b KQkq e3 1 1

while in Chess960 game that had Q and K swapped from the normal array the XFEN after 1.e4 woud be

rnbkqbnr/pppppppp/8/8/4P3/8/PPPP1PPP/RNBKQBNR b KQkq - 1 1

?

[Sven]

... XFEN is apparently not upward compatible with FENs for normal Chess as defined by the PGN standard...

PGN does not state any FEN standard for variants. Thus it is only important, whether FEN extensions are compatible to notations of traditional chess positions.

XFEN is fully downward compatible to FEN whereas Shredder FEN is producing different notations for positions which could either be interpreted as coming from Chess960 or from traditional Chess.

HGM made a statement about XFEN compared to FEN standard w.r.t. ep square. I can't imagine how this relates to Shredder FEN, "variants", or Chess960 where the key point is the representation and handling of castling rights.

Regarding compatibility, please do the following:
1. Consider the initial position for standard chess, which is also one of the 960 official starting positions for Chess960.
2. Make the move 1.e4 from there.
3. Post the resulting FEN and X-FEN after 1.e4, and compare them.

I know that your X-FEN version of ep square representation is "better" than that of FEN, and I have the same opinion as stated by several people above that programs should internally ignore an ep square coming from FEN if no ep capture is (pseudo-) legal, especially to avoid problems with repetition detection. But nevertheless, as long as the FEN standard officially has this hole then X-FEN should not be regarded as "fully downward compatible" with FEN. (I guess HGM meant "downward" although he wrote "upward", since FEN is the older standard.)

Sven

[Sven]

Interesting - you had nearly the same idea as I within a few minutes. But you mixed up your quoting, though

Sven

[mcostalba]

Code: Select all

// En passant square -- ignore if no capture is possible

Maybe the comment should be slightly improved like:

Code: Select all

// En passant square -- ignore if no pseudo-legal capture is possible

since pins preventing a pseudo-legal ep capture are not evaluated.

Thanks Sven for pointing out this, but I would think that the specifaction should be added if the opposite was true: If only legal captures were allowed then we should write it, instead, writing just "captures" without further specification it takes in account both legal and non legal, aka pdeudo-legal.

[Sven]

Code: Select all

// En passant square -- ignore if no capture is possible

Maybe the comment should be slightly improved like:

Code: Select all

// En passant square -- ignore if no pseudo-legal capture is possible

since pins preventing a pseudo-legal ep capture are not evaluated.

Thanks Sven for pointing out this, but I would think that the specifaction should be added if the opposite was true: If only legal captures were allowed then we should write it, instead, writing just "captures" without further specification it takes in account both legal and non legal, aka pdeudo-legal.

You may view it this way. But note that it makes a difference. If you don't evaluate pins at that place (I guess nobody does, though) then you translate an ep square from FEN into an internal ep square if there is at least one adjacent enemy pawn. Now if this initial position is repeated later on you miss to detect it since the internal ep square has been cleared in the meantime (repetition = no pawn move = no ep square).

Therefore not ignoring FEN ep squares even if a pseudo-legal ep capture would be illegal has "functional impact", so I would explicitly document it, or implement the pin evaluation instead. For me it is just a matter of documenting known restrictions, even if "all" engines have the same restriction.

Sven

[mcostalba]

Therefore not ignoring FEN ep squares even if a pseudo-legal ep capture would be illegal has "functional impact"

I don't think I have understood this. Could you pelase do an example of a test case where we could have an issue ?