Does a "en passent" aware PGN2EPD converter exist

Discussion of chess software programming and technical issues.

Moderators: bob, hgm, Harvey Williamson

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
tpetzke
Posts: 686
Joined: Thu Mar 03, 2011 3:57 pm
Location: Germany
Contact:

Does a "en passent" aware PGN2EPD converter exist

Post by tpetzke » Mon Oct 03, 2011 12:32 pm

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.

User avatar
hgm
Posts: 24651
Joined: Fri Mar 10, 2006 9:06 am
Location: Amsterdam
Full name: H G Muller
Contact:

Re: Does a "en passent" aware PGN2EPD converter ex

Post by hgm » Mon Oct 03, 2011 1:20 pm

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

User avatar
Evert
Posts: 2929
Joined: Fri Jan 21, 2011 11:42 pm
Location: NL
Contact:

Re: Does a "en passent" aware PGN2EPD converter ex

Post by Evert » Mon Oct 03, 2011 2:09 pm

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
Posts: 434
Joined: Mon Apr 24, 2006 6:06 pm
Contact:

Re: Does a "en passent" aware PGN2EPD converter ex

Post by Rémi Coulom » Mon Oct 03, 2011 2:44 pm

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
Posts: 686
Joined: Thu Mar 03, 2011 3:57 pm
Location: Germany
Contact:

Re: Does a "en passent" aware PGN2EPD converter ex

Post by tpetzke » Mon Oct 03, 2011 3:15 pm

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
Posts: 686
Joined: Thu Mar 03, 2011 3:57 pm
Location: Germany
Contact:

Re: Does a "en passent" aware PGN2EPD converter ex

Post by tpetzke » Mon Oct 03, 2011 3:16 pm

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
Posts: 861
Joined: Mon Jan 15, 2007 10:23 am
Location: Warsza
Contact:

Re: Does a "en passent" aware PGN2EPD converter ex

Post by PK » Mon Oct 03, 2011 4:43 pm

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.

User avatar
Evert
Posts: 2929
Joined: Fri Jan 21, 2011 11:42 pm
Location: NL
Contact:

Re: Does a "en passent" aware PGN2EPD converter ex

Post by Evert » Mon Oct 03, 2011 5:12 pm

PK wrote: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
Posts: 3860
Joined: Thu May 15, 2008 7:57 pm
Location: Berlin, Germany
Full name: Sven Schüle
Contact:

Re: Does a "en passent" aware PGN2EPD converter ex

Post by Sven » Mon Oct 03, 2011 5:12 pm

PK wrote: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
Posts: 686
Joined: Thu Mar 03, 2011 3:57 pm
Location: Germany
Contact:

Re: Does a "en passent" aware PGN2EPD converter ex

Post by tpetzke » Mon Oct 03, 2011 6:21 pm

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

Post Reply