polyglot en passant square

[elcabesa]

Hi all, I just noticied that polyglot book and major engines only set the en passant square if the en passant square can be attacked by a pawn.
for example
position startpos moves e2e4 doesn't set the epsquare.

why?

[tpetzke]

Hi,

I was once also troubled by this and opened a thread about it.

http://www.talkchess.com/forum/viewtopi ... 0c79a2c68b

In summary: It helps a bit with hash tables hits as you get a bit more hits if you don't set it in positions where no ep capture is possible anyway.

Thomas...

[hgm]

Whether a Pawn reached the 4th rank by a double-push on the previous move, or in another way, does not make the position any different if there is no Pawn to e.p. capture. Imagining they are different would be an artifact, which would have to be corrected by storing multipl versions of such a position (in an opening book), or would lead you to search positions that you searched before (in a hash table). None of that is good, and there is no up side.

[Don]

Whether a Pawn reached the 4th rank by a double-push on the previous move, or in another way, does not make the position any different if there is no Pawn to e.p. capture. Imagining they are different would be an artifact, which would have to be corrected by storing multipl versions of such a position (in an opening book), or would lead you to search positions that you searched before (in a hash table). None of that is good, and there is no up side.

Exactly. In theory you want each position to have only 1 fen representation if you are processing them. As it stands now a single 4 field fen position can have multiple fen representations due to this glitch.

The castling availability could also be a problem if it were not specified which order these are present. But the standard wisely requires them to be in the order KQkq - otherwise there would be even more ways to represent the same identical position.

Having said that, Komodo can process these out of order but there is function in Komodo to export fen (mostly for debugging) which follows the standard for castling.

Komodo also exports fen with correctly with respect to en-passant and I urge all software developers to NOT follow the standard in this regard. As far as I know it will not break ANY software and is a clear improvement.

[Don]

Whether a Pawn reached the 4th rank by a double-push on the previous move, or in another way, does not make the position any different if there is no Pawn to e.p. capture. Imagining they are different would be an artifact, which would have to be corrected by storing multipl versions of such a position (in an opening book), or would lead you to search positions that you searched before (in a hash table). None of that is good, and there is no up side.

Exactly. In theory you want each position to have only 1 fen representation if you are processing them. As it stands now a single 4 field fen position can have multiple fen representations due to this glitch.

What I meant to say is that a single position can have multipo 4 field representations.

The castling availability could also be a problem if it were not specified which order these are present. But the standard wisely requires them to be in the order KQkq - otherwise there would be even more ways to represent the same identical position.

Having said that, Komodo can process these out of order but there is function in Komodo to export fen (mostly for debugging) which follows the standard for castling.

Komodo also exports fen with correctly with respect to en-passant and I urge all software developers to NOT follow the standard in this regard. As far as I know it will not break ANY software and is a clear improvement.

[bob]

Hi all, I just noticied that polyglot book and major engines only set the en passant square if the en passant square can be attacked by a pawn.
for example
position startpos moves e2e4 doesn't set the epsquare.

why?

There is no pawn that can capture the e4 pawn...

[elcabesa]

understood, I also modified my code and now it can read polyglot books