Don wrote:fen is just fine for reading and writing by itself, there is no issue with bugs or loading the wrong position or anything like that. But have you ever had a bunch of PGN games that were non-standard? A good parser might be forgiving and not care whether you say "o-o", "O-O", "0-0" or "Kg1" but if you follow the standard there is only 1 way to represent any given move from a given position. That is how it should be.
Oh, I agree FEN has flaws. I don't like the way castling and EP are defined either. But it is there and wide spread and most of all: It fits its purpose, which is to describe a position as you can see it on a board, along with some flags that describe rights that may or may not be exercised in the position of one of its descendants. Any attempt to 'fix' its flaws by a more strict definition will fail due to the lack of compliance to the new definition. That is why I called this a non-issue. I'm just pragmatic.
I don't see what non-standard PGN files have to do with this discussion though. Not writing an ep-square when there is no EP possible is hardly an example of breaking the standard, as this would also be a legal position which is equivalent in all ways.
I just looked up the rule in the FIDE handbook and you're right:
Positions as in (a) and (b) areconsidered the same, if the same player has the move, pieces of the same kind and colour occupy the same squares, and the possible moves of all the pieces of both players are the same.
So far so good, but now a further clarification on castling rights:
When a king or a rook is forced to move, it will lose its castling rights, if any, only after it is moved.
Which means the positions are not identical.
So a better example is probably:
[d]k7/8/8/8/8/8/4q3/4K2R w K -
as repetions are not relevant here ...
Don wrote:fen is just fine for reading and writing by itself, there is no issue with bugs or loading the wrong position or anything like that. But have you ever had a bunch of PGN games that were non-standard? A good parser might be forgiving and not care whether you say "o-o", "O-O", "0-0" or "Kg1" but if you follow the standard there is only 1 way to represent any given move from a given position. That is how it should be.
Oh, I agree FEN has flaws. I don't like the way castling and EP are defined either. But it is there and wide spread and most of all: It fits its purpose, which is to describe a position as you can see it on a board, along with some flags that describe rights that may or may not be exercised in the position of one of its descendants. Any attempt to 'fix' its flaws by a more strict definition will fail due to the lack of compliance to the new definition. That is why I called this a non-issue. I'm just pragmatic.
I don't see what non-standard PGN files have to do with this discussion though. Not writing an ep-square when there is no EP possible is hardly an example of breaking the standard, as this would also be a legal position which is equivalent in all ways.
Your point is good, even if the standard is "fixed" nobody would ever trust it again. It serves it purpose just fine as is.
And nothing stops anyone from doing it the right way either as that should not break anything.
bob wrote:It's an issue if you process the FEN as text. For example, in unix, doing this:
sort FEN-file | uniq | wc -l
gives a wrong answer since the same position with and without EP target will be counted separately.
This only means that FEN cannot be used for such a thing. There's nothing we can do to change that. Besides: How useful is this when move counters are included in the FEN string? Even half-move counters are most of the time not really useful.
Richard.
bob wrote:It's an issue if you process the FEN as text. For example, in unix, doing this:
sort FEN-file | uniq | wc -l
gives a wrong answer since the same position with and without EP target will be counted separately.
This only means that FEN cannot be used for such a thing. There's nothing we can do to change that. Besides: How useful is this when move counters are included in the FEN string? Even half-move counters are most of the time not really useful.
Richard.
It's easy to compare just the first 4 fields with no programming using unix command line tools - so the fact that there are 6 fields is not important.
bob wrote:It's an issue if you process the FEN as text. For example, in unix, doing this:
sort FEN-file | uniq | wc -l
gives a wrong answer since the same position with and without EP target will be counted separately.
This only means that FEN cannot be used for such a thing. There's nothing we can do to change that. Besides: How useful is this when move counters are included in the FEN string? Even half-move counters are most of the time not really useful.
Richard.
It's easy to compare just the first 4 fields with no programming using unix command line tools - so the fact that there are 6 fields is not important.
That's exactly what I wanted to add: only the first 4 fields must be looked at when thinking about identity of FENs resp. positions. While different FENs for identical positions are annoying, one must of course never expect identical FEN entries in field 5 or 6 since the fifty move counter and the full move number are irrelevant when comparing two positions w.r.t. repetition (that is the definition of "identical positions" we should always refer to).
pijl wrote:I just looked up the rule in the FIDE handbook and you're right:
Positions as in (a) and (b) areconsidered the same, if the same player has the move, pieces of the same kind and colour occupy the same squares, and the possible moves of all the pieces of both players are the same.
So far so good, but now a further clarification on castling rights:
When a king or a rook is forced to move, it will lose its castling rights, if any, only after it is moved.
Which means the positions are not identical.
So a better example is probably:
[d]k7/8/8/8/8/8/4q3/4K2R w K -
as repetions are not relevant here ...
Richard.
I'm glad to read that my intuition was right. As to your new example, it is correct that now there aren't any repetitions possible. As you have shown by yourself, castling flags are still relevant: the same position could be reached via a path where White had already moved the king and/or rook forth and back and then Black played Qe2+ (or Qxe2+). And that other position would be different from the one you gave just for the missing castling right, which would be important not in the context of repetition detection but of correct hash key setting.
Again, I see no requirement for engines regarding internal correction of castling rights, as opposed to the EP case where correcting the internal EP square *can* be necessary in few special cases mentioned in this thread (not restricted to FEN conversion!) but *might* slow down the search somehow.
hgm wrote: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 don't like the way the ep is encoded as the destination square in FEN. It is sufficient knowing side to move just to specify the file of the target pawn and only needed if there is an enemy pawn in the right position to make an ep capture. If there is no such pawn then the encoder need not store it as a possible ep capture destination in the FEN string.
If that is what XFEN proposes then I think it makes sense since it doesn't alter the moves generated and maps two otherwise identical positions with different FEN notation into one.
There are implicit rook not moved indicators in the castling rights so that was perhaps an unfortunate choice of example.
Putting a ghost marker into the FEN string like "e" or "E" for the EP target square might be more logical than having an external tag.
The letter 'E' is not suitable, as it already stands for "Elephant". A non-alphanumeric character would be acceptable, though. (But note that '+' and '~' are aready taken as promotion indicators.)
But the whole exercise would still be pointless if it would indicate the e.p. square in the presence of neighboring Pawns that are not alowed to captured. If the ability to e.p. capture is to play a rule, it _must_ be on basis of legal moves.
And if we are going to break compatibility with existing FEN standards by introducing a new one, we might as well get rid of the KQkq notation for castling rights as well, and adopt HAha...
pijl wrote:I just looked up the rule in the FIDE handbook and you're right:
Positions as in (a) and (b) areconsidered the same, if the same player has the move, pieces of the same kind and colour occupy the same squares, and the possible moves of all the pieces of both players are the same.
So far so good, but now a further clarification on castling rights:
When a king or a rook is forced to move, it will lose its castling rights, if any, only after it is moved.
Which means the positions are not identical.
So a better example is probably:
[d]k7/8/8/8/8/8/4q3/4K2R w K -
as repetions are not relevant here ...
Richard.
I'm glad to read that my intuition was right. As to your new example, it is correct that now there aren't any repetitions possible. As you have shown by yourself, castling flags are still relevant: the same position could be reached via a path where White had already moved the king and/or rook forth and back and then Black played Qe2+ (or Qxe2+). And that other position would be different from the one you gave just for the missing castling right, which would be important not in the context of repetition detection but of correct hash key setting.
Again, I see no requirement for engines regarding internal correction of castling rights, as opposed to the EP case where correcting the internal EP square *can* be necessary in few special cases mentioned in this thread (not restricted to FEN conversion!) but *might* slow down the search somehow.
Sven
It is clear that black played Qxe2+ and not Qe2+ without a capture(otherwise castling cannot be in the FEN)
In case that Qe2+ is the last move of black it means that the last move of white before Qe2+ was Ke1 or Rh1 and white cannot castle.
The position is legal only because it is possible that white play a move like Bf1-e2 or Qd1-e2 and black replied Qxe2+
