Programmer bug hunt challenge

[hgm]

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...

[Stan Arts]

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...

That's a cause for bugs in many chessprograms though, including mine.
That is: setting e.p. rights when no pawn is there, and also use it for hashing and rep.detection.
In (I believe) 2004 at a Leiden tournament against Kallisto-II my program thought it was better (it was a pawn up) but did not avoid a rep.draw because of this bug. (it allowed a third repetition because it thought the first position was different because of a pawn being played up the initial 2 squares before the position, even though there was no pawn to capture e.p.)
I did not understand what had happened, after Kallisto declared draw I thought Kallisto had a bug till I went over the moves again and saw it was me with the bug.

Argh.

[Peter Fendrich]

and if I understand it right you also need a first move such as 1.a3 in this case, to trigger the ep reset. That combination must be extremely rare!

[steffan]

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.

[bob]

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...

[bob]

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.

[bob]

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.

[sje]

The simple workaround is to omit the en passant target square on the FEN unless a capture is possible.

[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.

[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.