Programmer bug hunt challenge

Discussion of chess software programming and technical issues.

Moderators: hgm, Harvey Williamson, bob

steffan
Posts: 28
Joined: Sat Mar 11, 2006 11:08 pm
Location: Midlands, England

Re: Programmer bug hunt challenge

Post by steffan » Fri May 04, 2007 7:24 pm

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.

bob
Posts: 20340
Joined: Mon Feb 27, 2006 6:30 pm
Location: Birmingham, AL

Re: Programmer bug hunt challenge

Post by bob » Fri May 04, 2007 8:19 pm

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

bob
Posts: 20340
Joined: Mon Feb 27, 2006 6:30 pm
Location: Birmingham, AL

Re: Programmer bug hunt challenge

Post by bob » Fri May 04, 2007 8:20 pm

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.

bob
Posts: 20340
Joined: Mon Feb 27, 2006 6:30 pm
Location: Birmingham, AL

Re: Programmer bug hunt challenge

Post by bob » Fri May 04, 2007 8:22 pm

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.

User avatar
sje
Posts: 4675
Joined: Mon Mar 13, 2006 6:43 pm

Re: Programmer bug hunt challenge

Post by sje » Sat May 05, 2007 12:28 am

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

Dann Corbit
Posts: 8537
Joined: Wed Mar 08, 2006 7:57 pm
Location: Redmond, WA USA
Contact:

Re: Programmer bug hunt challenge

Post by Dann Corbit » Sat May 05, 2007 1:36 am

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

Re: Programmer bug hunt challenge

Post by mambofish » Sat May 05, 2007 11:11 am

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.

User avatar
sje
Posts: 4675
Joined: Mon Mar 13, 2006 6:43 pm

Re: Programmer bug hunt challenge

Post by sje » Sat May 05, 2007 11:13 am

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.

mambofish

Re: Programmer bug hunt challenge

Post by mambofish » Sat May 05, 2007 11:15 am

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:

steffan
Posts: 28
Joined: Sat Mar 11, 2006 11:08 pm
Location: Midlands, England

Re: Programmer bug hunt challenge

Post by steffan » Sat May 05, 2007 11:17 am

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

Post Reply