Programmer bug hunt challenge

Discussion of chess software programming and technical issues.

Moderators: hgm, Harvey Williamson, bob

User avatar
hgm
Posts: 22195
Joined: Fri Mar 10, 2006 9:06 am
Location: Amsterdam
Contact:

Re: Programmer bug hunt challenge

Post by hgm » Fri May 04, 2007 4:54 pm

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

Re: Programmer bug hunt challenge

Post by Stan Arts » Fri May 04, 2007 5:27 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...

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

Re: Programmer bug hunt challenge

Post by Peter Fendrich » Fri May 04, 2007 5:34 pm

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

Post Reply