where FEN is not consistent

[smrf]

Because of the 50 move rule that number has significance. Thus such FENs have to be different.

[mathmoi]

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.

Humm, I see my error. I assumed one could take en passant, that's not the case.

[Gerd Isenberg]

Steven's approach: http://www.talkchess.com/forum/viewtopi ... 15&t=23806
Conclusion: if writing FEN, en passant target square should only written if ep is really possible. If reading (old) FEN with ep target set, one should not rely that ep is possible, to correct it inside an internal or external FEN-parser instance.

[Don]

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.

I cannot refute what you are saying. However ...

For some of the work I've done such as opening book searches and verification where you are definitely interesting in transpositions, only the first 4 fields have much relevance. In the same way that GHI is ignored in chess program hash tables for efficiency reasons, there is good reason to ignore the half move clock and the move number in fen. I would point out that fen is already broken with respect to GHI anyway and half move clock and move number does very little toward solving that. It solves the 50 move rule issue but ignores other GHI issues.

So I know it's a matter of preference when it's all broken anyway but I would like to see it be the case that for ANY position in chess, only a single "4 field" fen should be possible. It just seems to me that from an engineering stand point not having it this way makes it even more broken.

[bob]

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.

while that is true, the following is also true. The following snippets are all legal and identical, except that a character string match will fail:

8/4n3/...
8/22n3/...
8/1111n111/...

etc.

The idea is to provide something like SAN, which is pretty well defined, to produce the shortest (but consistent) move representation, rather than the ugly long algebraic stuff like e2e4 and such. An EP target when no EP is possible makes little sense to me.

[smrf]

It seems to be sufficient to test, whether a double stepping pawn will be placed beside an opposite pawn, then an e.p. flag will make sense. (That way XFEN handles that problem.) There is no functional need to also probe, whether that moving pawn e.g. would be pinned or not. The consistence of FEN would be increased clearly anyway in most cases.

[hgm]

Everything that can be brought as an objection to having different e.p. field for positions when there are no Pawns next to the moved Pawn is just as valid in cases where there are Pawns, but they do not have a legal e.p. capture. (This can not only happen because the neighbor Pawn is pinned, btw, but also because the side that should make the e.p. capture is in check.)

So nothing is really gained by only testing for neighbor Pawns. It remains a half-baked solution, that would certainly not make it worthwile to break backward compatibility.

String comparison between FENs is a bad idea anyway. Note that WinBoard uses the UFEN standard, which does not allow fancyful notation as given by Bob: writing 11 there in stead of 2, really means 11 empty squares.

[Gerd Isenberg]

Everything that can be brought as an objection to having different e.p. field for positions when there are no Pawns next to the moved Pawn is just as valid in cases where there are Pawns, but they do not have a legal e.p. capture. (This can not only happen because the neighbor Pawn is pinned, btw, but also because the side that should make the e.p. capture is in check.)

Or even ep-inned
[d] 3R4/8/8/1r1Pp2K/8/8/3k4/8 w - e6 0 1

So nothing is really gained by only testing for neighbor Pawns. It remains a half-baked solution, that would certainly not make it worthwile to break backward compatibility.

String comparison between FENs is a bad idea anyway. Note that WinBoard uses the UFEN standard, which does not allow fancyful notation as given by Bob: writing 11 there in stead of 2, really means 11 empty squares.

100% agreed.

[smrf]

... So nothing is really gained by only testing for neighbor Pawns. ...

Selecting between FEN, Shredder-FEN and XFEN I will chose XFEN. I will lose nothing but will gain a lot. And it is avoiding also e.g. the silly redefining of traditional chess FENs by Shredder-FEN when regarding it as descendants of a Chess960 position especially from pos. 518.

[Sven]

Everything that can be brought as an objection to having different e.p. field for positions when there are no Pawns next to the moved Pawn is just as valid in cases where there are Pawns, but they do not have a legal e.p. capture. (This can not only happen because the neighbor Pawn is pinned, btw, but also because the side that should make the e.p. capture is in check.)

So nothing is really gained by only testing for neighbor Pawns. It remains a half-baked solution, that would certainly not make it worthwile to break backward compatibility.

When I mentioned the "neighbor Pawn is pinned" case I forgot the possibility of the double-stepping pawn giving a discovered check. Thanks for pointing that out.

So a "perfect" system would test for pins and also test whether the moving side is in check but not by the double-stepping pawn. This is not cheap, of course, which may be the major reason for engines not caring about that special case.

Sven