Does a "en passent" aware PGN2EPD converter exist

[tpetzke]

Hi,

I'm looking for PGN2EPD converter that converts a PGN file into a set of EPD positions with a bm or pm specifying the played move.

So far I'm aware of the tools by Rémi Coulom and Tim Foden which seem to not fill the en passent data field in the created epd records.

Is there a tool that does it correctly ?


Rémi Coulom's pgn2epd :
rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - bm e4;
rnbqkbnr/pppppppp/8/8/4P3/8/PPPP1PPP/RNBQKBNR b KQkq - bm e5;


Tim Foden's pgn2fen :
rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - fmvn 1; hmvc 0; pm e4;
rnbqkbnr/pppppppp/8/8/4P3/8/PPPP1PPP/RNBQKBNR b KQkq - fmvn 1; hmvc 0; pm e5;

Thomas...

PS.: I read somewhere a reference to a tool from a guy named Koundinya Veluri that might be able to do it, but I wasn't able to locate it. All links were dead.

[hgm]

You cannot capture e.p. in the given position, so why would you care? Are you sure they also leave out the e.p.rights when you can actually capture e.p.?

[Evert]

Any tool that reduces a set of games to a set of positions (in other words, book making programs) should do this.

[Rémi Coulom]

My tool only indicates ep capture if it is actually possible. eg:

Code: Select all

[Event ""]
[Site ""]
[Date "2011.10.03"]
[Round ""]
[White ""]
[Black ""]
[Result "*"]

1. e4 f5 2. e5 d5 3. exd6 *

Code: Select all

rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq - bm e4;
rnbqkbnr/pppppppp/8/8/4P3/8/PPPP1PPP/RNBQKBNR b KQkq - bm f5;
rnbqkbnr/ppppp1pp/8/5p2/4P3/8/PPPP1PPP/RNBQKBNR w KQkq - bm e5;
rnbqkbnr/ppppp1pp/8/4Pp2/8/8/PPPP1PPP/RNBQKBNR b KQkq - bm d5;
rnbqkbnr/ppp1p1pp/8/3pPp2/8/8/PPPP1PPP/RNBQKBNR w KQkq d6 bm exd6;

I know it may not be very standard, but it makes a lot more sense to behave that way.

[tpetzke]

Hi,

I noticed that.

I care for the ep because my engine creates standard compliant FEN strings. And if I zobrist hash a FEN string from a pseudo compliant EPD I get no match with my fully compliant FEN even if the position matches.

I can create code to work around this but I rather write a compliant EPD parser then if there is none already.

Whether it makes more sense to only list ep when it is possible I'm not sure because there seems a lot of inconsistency introduced by this eg some list the ep square even if the ep capture is illegal because the capturing pawn is pinned.

So the FEN standard is easy, consistent and cheap to calculate. I rather stick to it.

Thomas...

[tpetzke]

Hi,

I care for the ep because my engine creates standard compliant FEN strings. And if I zobrist hash a FEN string from a pseudo compliant EPD I get no match with my fully compliant FEN even if the position matches.

Thomas...

[PK]

From what You write I infer that You expect different hash for 1.d4 e6 2.c4 and 1.c4 e6 2.d4. IMHO it doesn't make much sense, crippling position recognition (hash table, opening book, you name it). Probably it is better to be non-compliant in this case.

[Evert]

From what You write I infer that You expect different hash for 1.d4 e6 2.c4 and 1.c4 e6 2.d4. IMHO it doesn't make much sense, crippling position recognition (hash table, opening book, you name it). Probably it is better to be non-compliant in this case.

In addition to that, this is also inconsistent with the FIDE rules, which state that for the purpose of determining repetitions positions are the same only if pawns that can be captured en-passant in one position can also be captured en-passant in the other. In other words, if there is no way to capture a pawn en-passant after a double move, then you should not set the en-passant square.
There's some prior threads discussing this.

I agree, it's better to not follow the EPD standard too closely in this case.

[Sven]

From what You write I infer that You expect different hash for 1.d4 e6 2.c4 and 1.c4 e6 2.d4. IMHO it doesn't make much sense, crippling position recognition (hash table, opening book, you name it). Probably it is better to be non-compliant in this case.

Exactly. This topic has been discussed here a couple of times. In some cases also a repetition may be missed (e.g. 1.d4 e6 2.c4 Nf6 3.Nc3 Ng8?! 4.Nb1?!, which is a repetition but an implementation conforming 100% to the FEN/EPD standard will miss it due to the misleading e.p. target square "c3" after 2.c4).

A good compromise may be to make pseudo-legality of the e.p. capture a requirement for setting the e.p. target square, which means that there must be an enemy pawn left or right to the destination square of a pawn double step move. That will already remove most of the trouble without any noticeable effort. The "perfect" solution includes legality check of the e.p. capture, too.

Sven

[tpetzke]

Thanks for the replies, I will think about it. But I still don't like the implementation of a standard in a Microsoft way.

I then have to guess what rules the epd creator implemented in order to decide whether he includes an en passent square or not in a given FEN. Errors introduced by guessing can be much worse than a missed repetition.

Thomas...