FEN string

[cms271828]

Hi, is this fen string (from http://en.wikipedia.org/wiki/Forsyth%E2 ... s_Notation) correct?

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

I believe it is wrong since there are no black pawns adjacent to e4 pawn, so shouldn't the enpassant data be - instead of e3 ?

Thanks

[Sven]

Hi, is this fen string (from http://en.wikipedia.org/wiki/Forsyth%E2 ... s_Notation) correct?

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

I believe it is wrong since there are no black pawns adjacent to e4 pawn, so shouldn't the enpassant data be - instead of e3 ?

Thanks

According to the standard, yes, it is "correct" as it is stated there:

This is recorded regardless of whether there is a pawn in position to make an en passant capture.

This has been a topic a couple of times here. I think you can find some articles by searching for "PGN" or "en passant" together with my name but of course there will be even more threads in the past about it where I did not participate.

The key points are:

- Even if an engine receives an FEN string with an ep target square set the engine should take care to set its internal representation more "clever", e.g. by taking into account the existence of adjacent enemy pawns.

- But even then, the internal representation will not be perfect due to the possibility of pins making some pseudo-legal ep captures illegal in fact. This aspect has also a very tiny impact on repetition detection for very rare cases where a repetition might be missed if an engine sets its internal ep target square even though the ep capture is an illegal move, and the repeated position is seen as "different" due to not having the ep square set any longer.

- Making the internal ep target square definition "perfect" by considering also pins might be a performance issue, although I don't know if anyone has really tried it.

Sven

[sje]

The original FEN specification is a bit wonky on this point. When it was being written, there was considerable activity on the rec.games.chess.computer newsgroup and in e-mail about the presence or absence of the en passant target square based on position history. My original intent was to have the e.p. target appear only when at least one en passant capture was possible, but there was way, way too much opposition to this, so I caved.

That was a mistake on my part. A related mistake was to specify a square when a file letter would suffice.

In all of my recent work and for all my future work, the en passant target square as seen in FEN and EPD data will appear only if a real en passant capture can be made. Note that this means that no checkmate or stalemate position may have an e.p. target listed. If a position is fed into my latest code with a bogus e.p. target that would have been accepted using the original spec, then that target is silently deleted.

The code to implement this as fairly simple, particularly if the program already understands pins, something that is needed for a legal-only move generator. There is a side benefit in that bogus e.p. targets aren't present at any point, so they can't screw up a transposition table with duplicate entries.

[marcelk]

In all of my recent work and for all my future work, the en passant target square as seen in FEN and EPD data will appear only if a real en passant capture can be made.

Thank goodness. But this one is relatively easy...

The next thing is bogus castling flags? For example, when in check and all valid replies give up a castling flag, then it shouldn't appear in the position in the first place.

(There might exist some puzzle-like positions where castling is never reachable and there is no simple rule to determine if this is the case.)

[sje]

If a program incorporates a typical bitboard database in its position structure/class, then the implementation of bogus e.p. target cancellation needs only a few lines of code:

Code: Select all

(defun is-en-passant-move-playable? (my-pos my-epmove)
  "Determine if a given en passant capture move is legal in the given position."
  (let*
    (
      (result    nil)
      (bbdb      (pos-bbdb my-pos))
      (good      (pos-good my-pos))
      (good-pawn (color->pawn good))
      (evil      (pos-evil my-pos))
      (evil-pawn (color->pawn evil))
      (frsq      (move-frsq my-epmove))
      (epsq      (pos-epsq my-pos))
      (vpsq      (calc-ep-victim-sq good epsq))
    )
    (bbdb-del-man bbdb vpsq evil-pawn)
    (bbdb-mov-man bbdb frsq epsq good-pawn)
    (when (bb-sq-reset? (svref (bbdb-atkbc bbdb) evil) (svref (pos-ksqv my-pos) good))
      (setf result t))
    (bbdb-mov-man bbdb epsq frsq good-pawn)
    (bbdb-add-man bbdb vpsq evil-pawn)
    result))

The action requires a two line update of the bitboard database, a test for check, and then a two line reversion of the database. The rest of the position's components need not be changed, so the whole operation doesn't take too long.

[Dann Corbit]

This is the best improvement I could have hoped for.
It has caused me no end of torment.

[sje]

How often does a bogus pseudolegal (but not legal) en passant target appear? This would be a position where the last move was a double square pawn advance with the moving pawn ending on a square horizontally adjacent to at least one opposite color pawn, but no real en passant capture is available.

In a file of 100,000 checkmate positions generated from random games, only six of the positions had a bogus pseudolegal en passant target. (No checkmate position should have an en passant capture available; no moves at all, just like stalemates.)

In a file of 100,000 stalemate positions, none had a bogus pseudolegal en passant target. In a file of 100,000 mate-in-1 positions, only one had a bogus pseudolegal en passant target.

[wgarvin]

How often does a bogus pseudolegal (but not legal) en passant target appear? This would be a position where the last move was a double square pawn advance with the moving pawn ending on a square horizontally adjacent to at least one opposite color pawn, but no real en passant capture is available.

In a file of 100,000 checkmate positions generated from random games, only six of the positions had a bogus pseudolegal en passant target. (No checkmate position should have an en passant capture available; no moves at all, just like stalemates.)

In a file of 100,000 stalemate positions, none had a bogus pseudolegal en passant target. In a file of 100,000 mate-in-1 positions, only one had a bogus pseudolegal en passant target.

Thanks for those statistics.

We've discussed the pseudolegal en passant thing before and I remember arguing that it could cause the engine to miss a 3-fold repetition. But these numbers suggest that if you ask the extra question of "how often does a bogus pseudolegal en passant target occur during a 3-fold repetition sequence" the answer will be "practically never".

[sje]

A typo: I meant to write SEVEN and not SIX checkmate positions in my earlier post. Here are the seven positions out of 100,000 checkmates with a bogus pseudolegal en passant target:

Code: Select all

1nb2b1n/rp4r1/2B5/p2p1pP1/1p1Pp1Pp/1RP4K/P1k1Q3/R1B3N1 b - d3 0 38 id checkmates.09516
1nb2bkr/7p/2P5/p3pP1n/P2P1P1P/K5p1/2q5/1NQ1N2R w - e6 0 40 id checkmates.09543
3R2n1/5pr1/p6b/2P3pk/PrP1Q1Pp/1P2pP2/4P3/3K1BNR b - g3 0 41 id checkmates.28259
3n4/p4p2/1pb1R3/1rNk1P2/1PPp2P1/b2Q2P1/P2P4/1RBK4 b - c3 0 48 id checkmates.32893
8/n3R3/5p2/p4krP/P3Pp1P/1b3Q2/1pP4N/4RK2 b - e3 0 55 id checkmates.77696
rn3bnr/pb1q2p1/3p1pPk/2p1p2p/2pP4/PP3P1P/4P1R1/RNBQKB2 b Q d3 0 17 id checkmates.97289
rnbq2nr/1p1p4/1Ppp4/p4p1p/2kPPpPb/PRP5/5P1P/3QKB1R b - e3 0 23 id checkmates.99269

[marcelk]

As said, bogus castling flags are far more common (Qxd1+ ...) How about considering to take them out as well? There are positions where this is hard to determine, such as the one below

[D]4k3/8/8/8/8/8/7p/4KB1R w K -

But a 1 ply consideration should take care of all the practical cases.