Most likely. Then a new movelist is generated wich has 2 pawns going to a3 (a2 and b2) Since captures are likely generated first, whites first move becomes b2xa3
1. It's of course an impossible ep capture for white
2. There's an ambiguity.
3. Move 29. ... Bxb2 becomes impossible.
4. When you go back in the game a ghost black pawn could indeed appear on a2 although there's already a white pawn there.
Why should your suggestion be a merely PGN parsing related error? It also should have occurred already earlier at a lot of other moments. Thus I would exclude that idea.
Most likely. Then a new movelist is generated wich has 2 pawns going to a3 (a2 and b2) Since captures are likely generated first, whites first move becomes b2xa3
1. It's of course an impossible ep capture for white
2. There's an ambiguity.
3. Move 29. ... Bxb2 becomes impossible.
4. When you go back in the game a ghost black pawn could indeed appear on a2 although there's already a white pawn there.
A lot of these logical checks are "optimized" out of my engine .
The possibilities I mentioned are not guesses what Rebel will do, they are descriptions what my engine will do.
1. My engine takes a bitboard of the opponent pieces and or's it with the ep square. It is then fed to the pawnattack bitboard so the ep move will show up.
2. My engine generates a legal move list (when pgn parsing). The first move that fullfils the criteria (Pawn moving to a3) will be taken.
3. No problem, my engine captures allways. With a noncapture move, the captured piece will be "Empty" rather than a piece.
4. Yes, a2 instead of a4. The white pawn on a2 will be overwritten with a black pawn. No check is done for that.
Rob wrote:Didn't clear en passent square between games?
Bravo!
Funny because my PGN parser is about to celebrate its first decade and the bug has been there all along, it seems that it is rare a game to end with white moves like a4/b4 etc.
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...
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.
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.
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...
.