where FEN is not consistent

[smrf]

See the two PGN examples:

[Event ""]
[Site ""]
[Date "2010.01.06"]
[Time "16:45:18"]
[Round ""]
[White "White"]
[Black "Black"]
[Result "*"]

1. e4 e5 2. d3 *


[Event ""]
[Site ""]
[Date "2010.01.06"]
[Time "16:45:18"]
[Round ""]
[White "White"]
[Black "Black"]
[Result "*"]

1. d3 e5 2. e4 *

Both end in identical positions, but FEN demands for different FEN strings. XFEN instead decides to not use any e.p. flag in both cases. Thus XFEN reduces such divergences without creating any problem.

rnbqkbnr/pppp1ppp/8/4p3/4P3/3P4/PPP2PPP/RNBQKBNR b KQkq - 0 2

[bob]

See the two PGN examples:

[Event ""]
[Site ""]
[Date "2010.01.06"]
[Time "16:45:18"]
[Round ""]
[White "White"]
[Black "Black"]
[Result "*"]

1. e4 e5 2. d3 *


[Event ""]
[Site ""]
[Date "2010.01.06"]
[Time "16:45:18"]
[Round ""]
[White "White"]
[Black "Black"]
[Result "*"]

1. d3 e5 2. e4 *

Both end in identical positions, but FEN demands for different FEN strings. XFEN instead decides to not use any e.p. flag in both cases. Thus XFEN reduces such divergences without creating any problem.

rnbqkbnr/pppp1ppp/8/4p3/4P3/3P4/PPP2PPP/RNBQKBNR b KQkq - 0 2

I think, and have said often, that this idea is both stupid and broken. In Crafty, a bogus EP target will cause problems. So when I parse a FEN string, I have to look for the ep target and verify that an ep capture is actually possible, otherwise I zero the target and ignore that part of the FEN. I see no reason to call this an EP target square. Why not just call it a double-pawn-move indicator instead, which is really what it is.

It is broken, and should be fixed regardless of backward compatibility issues. The good thing is that if you produce a FEN string, you can do this correctly without breaking anybody's code. And your FEN parser can "fix the problem" also. But it is an unnecessary and ugly requirement.

[Don]

I completely agree with this. It also makes comparing 2 positions impossible whether the only difference is whether an en-passant capture is possible.

See the two PGN examples:

[Event ""]
[Site ""]
[Date "2010.01.06"]
[Time "16:45:18"]
[Round ""]
[White "White"]
[Black "Black"]
[Result "*"]

1. e4 e5 2. d3 *


[Event ""]
[Site ""]
[Date "2010.01.06"]
[Time "16:45:18"]
[Round ""]
[White "White"]
[Black "Black"]
[Result "*"]

1. d3 e5 2. e4 *

Both end in identical positions, but FEN demands for different FEN strings. XFEN instead decides to not use any e.p. flag in both cases. Thus XFEN reduces such divergences without creating any problem.

rnbqkbnr/pppp1ppp/8/4p3/4P3/3P4/PPP2PPP/RNBQKBNR b KQkq - 0 2

I think, and have said often, that this idea is both stupid and broken. In Crafty, a bogus EP target will cause problems. So when I parse a FEN string, I have to look for the ep target and verify that an ep capture is actually possible, otherwise I zero the target and ignore that part of the FEN. I see no reason to call this an EP target square. Why not just call it a double-pawn-move indicator instead, which is really what it is.

It is broken, and should be fixed regardless of backward compatibility issues. The good thing is that if you produce a FEN string, you can do this correctly without breaking anybody's code. And your FEN parser can "fix the problem" also. But it is an unnecessary and ugly requirement.

[hgm]

I think the most convenient way to fix the problem is simply to rename the field: call it a Pawn double-push field, rather than an e.p. field. That would solve all problems, without actually changing anything.

[Don]

I think the most convenient way to fix the problem is simply to rename the field: call it a Pawn double-push field, rather than an e.p. field. That would solve all problems, without actually changing anything.

I think the issue is more fundamental that just a renaming issue. There is no need in fen to have a double-push field since we don't really care about that except with respect to en-passant. We don't have rook just moved fields or anything like that.

In my view the issue is that you can have 2 identical positions with different fen and that is ugly and non-uniform.

I have done opening book and other stuff using fen where I needed this to actually make logical sense and end up searching separate positions that are identical from the programs point of view.

I feel obligated to mention that fen doesn't really capture a game state anyway, even if this particular issue were fixed because 2 positions could have different history that is actually relevant to the search. I'm talking about GHI issues.

[mathmoi]

See the two PGN examples:

[Event ""]
[Site ""]
[Date "2010.01.06"]
[Time "16:45:18"]
[Round ""]
[White "White"]
[Black "Black"]
[Result "*"]

1. e4 e5 2. d3 *


[Event ""]
[Site ""]
[Date "2010.01.06"]
[Time "16:45:18"]
[Round ""]
[White "White"]
[Black "Black"]
[Result "*"]

1. d3 e5 2. e4 *

To me these are two different positions, since the legal moves in both are not the sames. Can someone explain in which circumstance theses positions are considered the same and why one can't just ignore the ep field in this case?

[Gian-Carlo Pascutto]

To me these are two different positions, since the legal moves in both are not the sames.

The game you play is not chess then.

[Don]

See the two PGN examples:

[Event ""]
[Site ""]
[Date "2010.01.06"]
[Time "16:45:18"]
[Round ""]
[White "White"]
[Black "Black"]
[Result "*"]

1. e4 e5 2. d3 *


[Event ""]
[Site ""]
[Date "2010.01.06"]
[Time "16:45:18"]
[Round ""]
[White "White"]
[Black "Black"]
[Result "*"]

1. d3 e5 2. e4 *

To me these are two different positions, since the legal moves in both are not the sames. Can someone explain in which circumstance theses positions are considered the same and why one can't just ignore the ep field in this case?

These positions are the same in every way and could not cause even a GHI problem, but they would generate 2 different fen strings.

If the knights then would come out, dance around, and then return to their home squares with no other moves it would be a fundamentally different positions because of the possibility of repetition draws or the so called GHI problem. But it would also generate the same fen as in your first example, but not the second.

However I don't propose that we try to address the GHI issues because that would require something quite a bit more elaborate.

But we SHOULD fix the first issue, it is just not logical the way it is. The fix is so easy because it doesn't break any existing software that I know of.

There is no good reason not to implement this the correct way when any of us right software. We could appeal to Steven Edwards who drafted the standard to make this revision.

[jhaglund]

The chess program is responsible to remember/store the en passant flag when generating a FEN position or playing a game.

That goes for any other programs also.

There is nothing wrong with two games or FENs. There is no en passant move for either of the games.

[hgm]

In my view the issue is that you can have 2 identical positions with different fen and that is ugly and non-uniform.

You would have that anyway: the move number could be different.