Excuses for Wishy Washy FEN/EPD/PGN implementation

[Deberger]

Oh yeah, we totally conform to industry specifications -- unless it's inconvenient.

Example 1:
>This Qxf7+ (checkmate) should be Qxf7#
Yeah well checkmate is definitely a check, so that's correct.

Example 2:
>Ngf3 should be Nf3, because the other knight is pinned.
Yeah well,
A) This is a rare case
B) and doesn't affect anything else
C) and it might break something if we try to fix it
D) and the specifications say it's acceptable.

Example 3:
>And what about the en passant square?
Oh yeah we definitely set that, but only if there's an adjacent pawn of the opposite color.

>What about pins and checks?
Yeah well,
A) This is a rare case
B) and doesn't affect anything else
C) and it might break something if we try to fix it
D) and the specifications say it's acceptable.
Bonus:
E) We are already doing you a huge favor by detecting adjacent pawns of the opposite color.
Don't ask us to verify that en passant is actually legal.

[Dann Corbit]

RE:
"Example 3:
>And what about the en passant square?
Oh yeah we definitely set that, but only if there's an adjacent pawn of the opposite color."

Setting a needless e.p. target square should be an imprisonable offense.
I suggest this, because I doubt the death penalty would be acceptable to the squeamish.

[Ovyron]

Setting a needless e.p. target square should be an imprisonable offense.
I suggest this, because I doubt the death penalty would be acceptable to the squeamish.

En passant target square in algebraic notation. If there's no en passant target square, this is "-". If a pawn has just made a two-square move, this is the position "behind" the pawn. This is recorded regardless of whether there is a pawn in position to make an en passant capture

Would this full implementation of FEN be considered a "needless e.p. target square"?

[Dann Corbit]

Setting a needless e.p. target square should be an imprisonable offense.
I suggest this, because I doubt the death penalty would be acceptable to the squeamish.

En passant target square in algebraic notation. If there's no en passant target square, this is "-". If a pawn has just made a two-square move, this is the position "behind" the pawn. This is recorded regardless of whether there is a pawn in position to make an en passant capture

Would this full implementation of FEN be considered a "needless e.p. target square"?

Yes, and I complained bitterly to Steven about it. He agreed that it was probably a defect in the standard. More than 95% of e,p. flags in the wild are spurious.

Here is the harm: if you fail to notice and do not strip them off, you will reanalyze positions again and again and again wasting computer time.

Consider this illustrative example:
[d]rnbqkbnr/8/8/pppppppp/PPPPPPPP/8/8/RNBQKBNR w KQkq -
If we reverse colors, we shold have at most 2 positions here. But with the e.p. flags (ALL OF THEM SPURIOUS) there are 16 positions, not 2. Therefore, if all the variants were stored in the database, you would analyze the same position 8 times in each direction.

What is the value of a spurious e.p.flag? I can't think of any. If the programmer can't remember one ply to reverse it, he should find another job.

[tmokonen]

I'm sorry, but having to check to see if a piece is pinned just to save a character of output is a royal pain in the ass to me, when all I want to do is have my engine print a move history. My PGN printing routine is a fair bit more complicated because of this requirement, and I have a hard time believing that a PGN parser would choke on a perfectly legal move with that extra character. There are other things about the PGN standard that I don't understand, such as needing all seven required tags (really, is Site that important?), and having those seven tags in a rigid order. And why repeat the game result in both the Result tag and at the end of the move list? Nevertheless, I kinda feel like I'm stomping on Steven's grave by nitpicking about stuff like this.

Off topic, but I see the PGN standard makes mention of a program called Slappy The Database. Did Steven ever release that program? I can't find any info on it other than the PGN standard.

[mar]

I hope you don't mean engine programmers, as we already have to cut through anyting that comes disguised as a FEN and remove invalid ep anyway.

The problem is that to detect invalid ep, it's not enough to check for opposing pawns, you still have to check if the pawn that might ep-capture is not pinned, not a big deal though. You still have to check that stm is not in check etc.

[Fulvio]

If we reverse colors, we shold have at most 2 positions here. But with the e.p. flags (ALL OF THEM SPURIOUS) there are 16 positions, not 2. Therefore, if all the variants were stored in the database, you would analyze the same position 8 times in each direction.

In that case, the greatest waste of resources is using FENs, not its ambiguous EP flag.
There are much more efficient ways of storing positions.
If your our only tool is a hammer, every problem looks like a nail.

[Ras]

In that case, the greatest waste of resources is using FENs

This is not about engine internal position storage, but when you get a bunch of test positions, and that's typically as text file.

[Fulvio]

This is not about engine internal position storage, but when you get a bunch of test positions, and that's typically as text file.

I don't get it: what's then the crime that deserves death penalty?
Can't the function that converts the FEN to the internal representation simply take care of the EP square?

[Dann Corbit]

In that case, the greatest waste of resources is using FENs

This is not about engine internal position storage, but when you get a bunch of test positions, and that's typically as text file.

Sometimes when everything looks like a hammer, someone picks one up and hits the nail square on the head.