Page 2 of 4

Re: Programmer bug hunt challenge

Posted: Fri May 04, 2007 9:24 pm
by steffan
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...
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 :
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.

Re: Programmer bug hunt challenge

Posted: Fri May 04, 2007 10:19 pm
by bob
Uri Blass wrote:I do not understand the bug

There was no enpassent capture possible in the end of the first game
so I do not see how clearing enpassent square between games could be relevant.

There was no black pawn at b4 in the final position of the game.

Uri
some programs incorrectly (IMHO) set an EP target whenever a pawn advances two squares, whether or not there are enemy pawns on adjacent files that could make an EP capture or not. I've never done this, and actually had to put some sanity checks in my FEN parsing to discard the EP target if there were no enemy pawns situated so they could actually make an EP capture in the given position.

I'd assume ed always setd the EP target to a3 when the a2 pawn advances to a4, regardless of whether there is a black pawn on b4 or not...

Re: Programmer bug hunt challenge

Posted: Fri May 04, 2007 10:20 pm
by bob
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...
It's maybe not a "bug", but it's a bad idea. Why say something is possible when it is not? After a2-a4, if there is no black pawn on b4, no EP capture is possible and setting the EP target to a3 makes no sense.

Re: Programmer bug hunt challenge

Posted: Fri May 04, 2007 10:22 pm
by bob
steffan wrote:
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...
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 :
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.
Yes, that has been one flaw in the FEN specification that should have been changed as it makes absolutely no sense.

Re: Programmer bug hunt challenge

Posted: Sat May 05, 2007 2:28 am
by sje
The simple workaround is to omit the en passant target square on the FEN unless a capture is possible.

Re: Programmer bug hunt challenge

Posted: Sat May 05, 2007 3:36 am
by Dann Corbit
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.

Re: Programmer bug hunt challenge

Posted: Sat May 05, 2007 1:11 pm
by mambofish
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.

Re: Programmer bug hunt challenge

Posted: Sat May 05, 2007 1:13 pm
by sje
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.
No, the castling availability potentially applies to all future positions, not just the next move.

Re: Programmer bug hunt challenge

Posted: Sat May 05, 2007 1:15 pm
by mambofish
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 :wink:

Re: Programmer bug hunt challenge

Posted: Sat May 05, 2007 1:17 pm
by steffan
Dann Corbit wrote:I think that the standard should redo e.p. so that the square is not named unless capture is possible.
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?
[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 :
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.
The part I want to draw attention to is the clause "the possible moves of all the pieces of both players are the same".

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