Yes, that has been one flaw in the FEN specification that should have been changed as it makes absolutely no sense.steffan wrote:Yes, precisely. Note it is also necessary to remember the en passant square for the purpose of writing FEN strings, even if there is no pawn present to effect the en passant capture. See last paragraph section 16.1.7 of the PGN specificiation :hgm wrote:Well, as the e.p. square here is only used to decide if the following move is legal, and not for determining if positions are different for hashing or applying the 3-rep rule, it is not a bug to consider that e.p. rights exist when no Pawn is present to enjoy these rights...An en passant target square is given if and only if the last move was a pawn advance of two squares. Therefore, an en passant target square field may have a square name even if there is no pawn of the opposing side that may immediately execute the en passant capture.
Programmer bug hunt challenge
Moderators: hgm, Rebel, chrisw
-
- Posts: 20943
- Joined: Mon Feb 27, 2006 7:30 pm
- Location: Birmingham, AL
Re: Programmer bug hunt challenge
-
- Posts: 4675
- Joined: Mon Mar 13, 2006 7:43 pm
Re: Programmer bug hunt challenge
The simple workaround is to omit the en passant target square on the FEN unless a capture is possible.
-
- Posts: 12541
- Joined: Wed Mar 08, 2006 8:57 pm
- Location: Redmond, WA USA
Re: Programmer bug hunt challenge
I think that the standard should redo e.p. so that the square is not named unless capture is possible. For example, what is the practical difference between these two positions:
[D]r2qk2r/ppp2ppp/2n2n2/1B1pp1B1/1b1PP1b1/2N2N2/PPP2PPP/R2QK2R w KQkq e6 0 2
[D]r2qk2r/ppp2ppp/2n2n2/1B1pp1B1/1b1PP1b1/2N2N2/PPP2PPP/R2QK2R w KQkq - 0 2
The significance of the change is that a search for the either position above should also return the other, because they are the same position.
[D]r2qk2r/ppp2ppp/2n2n2/1B1pp1B1/1b1PP1b1/2N2N2/PPP2PPP/R2QK2R w KQkq e6 0 2
[D]r2qk2r/ppp2ppp/2n2n2/1B1pp1B1/1b1PP1b1/2N2N2/PPP2PPP/R2QK2R w KQkq - 0 2
The significance of the change is that a search for the either position above should also return the other, because they are the same position.
Re: Programmer bug hunt challenge
Hmm... The position you give also indicates that both sides have castling rights. It does not state whether they can legally castle on their next move. In a FEN position the ep flag is viewed in the same way: as an indication that an ep capture on the named square might be available on the next move, not that an ep capture is necessarily legal.
If you change the rules for the ep field, you would presumably also have to change them for the castling field, to remain semantically consistent.
If you change the rules for the ep field, you would presumably also have to change them for the castling field, to remain semantically consistent.
-
- Posts: 4675
- Joined: Mon Mar 13, 2006 7:43 pm
Re: Programmer bug hunt challenge
No, the castling availability potentially applies to all future positions, not just the next move.mambofish wrote:If you change the rules for the ep field, you would presumably also have to change them for the castling field, to remain semantically consistent.
Re: Programmer bug hunt challenge
And what about the situation where the pawn move revealed a check on the enemy king? Even if an opposing pawn could theoretically capture e.p., this would also not be legal. Would you omit the e.p. square in this case as well from the FEN notation?
FEN says nothing about the legality of moves for the next player, and I personally think it should remain that way
FEN says nothing about the legality of moves for the next player, and I personally think it should remain that way
-
- Posts: 28
- Joined: Sun Mar 12, 2006 12:08 am
- Location: Midlands, England
Re: Programmer bug hunt challenge
There is a potential difficulty with that, the clause "unless capture is possible" needs stricter definition. What if the en passant capture is a pseudo-legal move but not a genuinely legal move i.e. it leaves the moving side in check?Dann Corbit wrote:I think that the standard should redo e.p. so that the square is not named unless capture is possible.
[D]1k6/3r4/8/3Pp3/8/3K4/8/6R1 w - e6 0 2
At present, it is not necessary to check for legal moves (psuedo-legal or otherwise) to write a FEN string. If the proposed change is to only name the en passant square when genuinely legal en passant capture(s) are possible, then programs writing FEN strings must check for the legality of moves i.e. become more complex.
On a related issue, for the purposes of 3-time repetition, section 9.2 of the FIDE Laws of Chess deem that a position is repeated only if :
The part I want to draw attention to is the clause "the possible moves of all the pieces of both players are 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. Positions are not the same if a pawn that could have been captured en passant can no longer in this manner be captured or if the right to castle has been changed temporarily or permanently.
With the current FEN standard, it is possible to have 2 chess positions which are considered a repetition by the FIDE laws, but have different en passant square encoding in FEN. For example:
[D]r3k3/8/8/4p3/4P3/8/8/1R2K3 w - - 0 2
[D]r3k3/8/8/4p3/4P3/8/8/1R2K3 w - e6 0 2
If we imagine the FEN standard were changed to only name the en passant square when genuinely legal en passant capture(s) are available, the last example shown is not possible. The conditions for position repetition then become exactly equivalent to :
if the corresponding first four fields of the FEN encoding for the positions are the same
-
- Posts: 20943
- Joined: Mon Feb 27, 2006 7:30 pm
- Location: Birmingham, AL
Re: Programmer bug hunt challenge
I think the right answer is that an EP target is given only when an EP capture is possible. The pinned pawn issue doesn't matter to me as much as the original case. But I can handle it however you throw it at me so it really doesn't matter. Same problem with PGN games. Too many screw up castling and use zero-zero (among others). Some put a space after 21. Ne5, others just produce 21.Ne5. I've made my parsing handle these odd cases over the years to avoid confusion when it would fail on a PGN read...mambofish wrote:And what about the situation where the pawn move revealed a check on the enemy king? Even if an opposing pawn could theoretically capture e.p., this would also not be legal. Would you omit the e.p. square in this case as well from the FEN notation?
FEN says nothing about the legality of moves for the next player, and I personally think it should remain that way
But following the standard would be nice, IMHO...
-
- Posts: 20943
- Joined: Mon Feb 27, 2006 7:30 pm
- Location: Birmingham, AL
Re: Programmer bug hunt challenge
I don't see where repetition (or even the 50 move rule) would be a problem. For there to be a true EP target (according to my terminology) the position could _not_ have occurred previously in the game, because a pawn must be pushed the previous move to generate an EP target. And once the pawn is pushed, the 3-fold repetition counter starts over as does the 50 move rule. So how could there be an ambiguity? And it is certainly legal for two identical positions to be converted to FEN, where one has the EP target and one does not. Because the one that does not did not have a pawn push the previous move...steffan wrote:There is a potential difficulty with that, the clause "unless capture is possible" needs stricter definition. What if the en passant capture is a pseudo-legal move but not a genuinely legal move i.e. it leaves the moving side in check?Dann Corbit wrote:I think that the standard should redo e.p. so that the square is not named unless capture is possible.
[D]1k6/3r4/8/3Pp3/8/3K4/8/6R1 w - e6 0 2
At present, it is not necessary to check for legal moves (psuedo-legal or otherwise) to write a FEN string. If the proposed change is to only name the en passant square when genuinely legal en passant capture(s) are possible, then programs writing FEN strings must check for the legality of moves i.e. become more complex.
On a related issue, for the purposes of 3-time repetition, section 9.2 of the FIDE Laws of Chess deem that a position is repeated only if :The part I want to draw attention to is the clause "the possible moves of all the pieces of both players are 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. Positions are not the same if a pawn that could have been captured en passant can no longer in this manner be captured or if the right to castle has been changed temporarily or permanently.
With the current FEN standard, it is possible to have 2 chess positions which are considered a repetition by the FIDE laws, but have different en passant square encoding in FEN. For example:
[D]r3k3/8/8/4p3/4P3/8/8/1R2K3 w - - 0 2
[D]r3k3/8/8/4p3/4P3/8/8/1R2K3 w - e6 0 2
If we imagine the FEN standard were changed to only name the en passant square when genuinely legal en passant capture(s) are available, the last example shown is not possible. The conditions for position repetition then become exactly equivalent to :if the corresponding first four fields of the FEN encoding for the positions are the same
-
- Posts: 27809
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: Programmer bug hunt challenge
It seems to me that requiring the e.p. field in a FEN to be only present if there actually is a legal e.p. capture just puts a completely needless burden on the routine that converts board positions to FENs. No information is lost by putting a superfluous e.p. square. A possible reader for which the presence of an actual capture makes any difference almost certainly will have the intelligence and information to figure out for itself if the capture exists, if it wants to know that.
FENs are designed as a tool to make life easy. So I think the existing standard made the good choice.
FENs are designed as a tool to make life easy. So I think the existing standard made the good choice.