tpetzke wrote:
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.
Nah. You only ever get a difference in situations where you did not set the ep square because no ep capture is possible - in which case the ep square is irrelevant.
Not that I think the missed repetition is actually relevant (Jazz doesn't do this right either, which has never bothered me).
tpetzke wrote: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 don't get it. What has the FEN string to do with a Zobrist hash? Why does an engine create FEN strings in the first place?
I'm not concerned here with a missed repetition, whatever an engine does internally eg. how it generates its hash signature is not subject to standards anyway, any engine can do this as it likes.
Standards rule when you communicate with the outside world, because if one party does not stick to it communication breaks.
I'll try the pawn presence check idea but if it slows down the engines makeMove I'll go back to my original signature creation.
And thirdly, the code is more what you'd call "guidelines" than actual rules. Welcome aboard the Black Pearl, Miss Turner .
Cpt. Barossa
I'm implementing an opening book for my engine, so in order to assemble the book I feed in a set of epds that contain a position and a move.
In this process a hash signature is created from the epd fen part. If the epd fen has no en passent square set although the standard says it should then my engine will not recognize that this position in its book is actually the position on the board.
tpetzke wrote:
In this process a hash signature is created from the epd fen part. If the epd fen has no en passent square set although the standard says it should then my engine will not recognize that this position in its book is actually the position on the board.
Only if your engine sets the EP square in the hash even when there is no EP capture possible, which is almost certainly wrong (there are no benefits, you miss transpositions/repetitions and it's actually not in accordance with FIDE rules).
Beware that not removing false e.p. rights will cause a serious slowdown of your engine, perhaps a hundred times as much as doing the tests for neighboring Pawns. Because it means that almost every position after a double push (and there are many in the middle game!) will now be represented by two different hash keys, leading to hash misses that would otherwise have been hits, with very costly superfluous searches as a result.
The benefit was that it is very easy to implement (branchless).
But I see with the hash behaviour your point and will try it out.
The argument with the FIDE rule I don't buy
This is how in the polyglot book format it is handled and I think this is how most engines do it. And this is also not compliant to FIDE rules.
If the opponent has performed a double pawn push and there is now a pawn next to it belonging to the player to move then "enpassant" ...is set. It is irrelevant if the potential en passant capturing move is legal or not (examples where it would not be legal are when the capturing pawn is pinned or when the double pawn push was a discovered check).
Well, as this is mostly a speed issue, a pragmatic approach suffices. Not being able to distinguish the positions after 1. d4 d5 2. c4 and 1. c4 d5 2. d4 is very costly because it happens very frequently, and causes needles searches when it does. Not being able to distinguish a position where a neighboring Pawn exists but happens to be pinned occurs a thousand times less frequently, and would take 100 times longer to check. So the duplication of positions in opening book and hash table (with an occasional re-search) is a much more efficient solution for this case.
In Spartacus' MakeMove I need to catch special moves with a branch anyway, and I make that catch double pushes as well, by encoding these as special moves. So other regular moves don't suffer from this a all:
I changed the en passent hash signature coding in iCE to the scheme suggested by Sven and Harm and did some quick perft tests with the old and new version
The raw perft (without hash table usage) performed about the same in both versions. 107 sec for perft 7 from the start position.
The perft that utilizes the hash table for storing sub results performed better in the new version as predicted by Harm, significantly better.
tpetzke wrote:
The argument with the FIDE rule I don't buy
This is how in the polyglot book format it is handled and I think this is how most engines do it. And this is also not compliant to FIDE rules.
I'm not sure there's anything for sell.
The EPD standard deviates from the FIDE rules for no clear reason, so adhering to it too rigorously doesn't seem particularly "right". You are right that most engines don't strictly follow FIDE rules for setting the EP square either (as I may have said, mine doesn't either). However, cases where it would matter are relatively rare and adding extra code to do the tests (basically a legal move test for the pawn capture) seems a lot of hassle and may be slow (no idea about that though, it may be rare enough that it doesn't actually matter). The worst that can happen is that a repetition is caught one move late, which isn't really a big deal.
