En passant target square field in FEN

[dlbbld]

According to the FEN specification, the en passant target square field is unconditionally set after each pawn two square advance.

An en passant target square is given if and only if the last move was a pawn advance of two squares. Therefore, an en passant target square field may have a square name even if there is no pawn of the opposing side that may immediately execute the en passant capture.

In the analysis board, after playing e4 from the starting position, the FEN is

rnbqkbnr/pppppppp/8/8/4P3/8/PPPP1PPP/RNBQKBNR b KQkq - 0 1

but should be

rnbqkbnr/pppppppp/8/8/4P3/8/PPPP1PPP/RNBQKBNR b KQkq e3 0 1

Can you please check this and explain why you are not implementing the FEN specification here? Thanks.

[benediktwerner]

It simply makes no appreciatable difference. As for the reason why it's done this way: As far as I can tell, it's to avoid running move generation when en passant is not possible and in order to ensure that positions are correctly considered equivalent for 3-fold repetition.

Btw, you can also use the discussions section for questions.

[dlbbld]

In my understanding, creating a standard approaches the problem, that if different programs produce different outputs for conceptionally identical problems, this usually results in a bunch of problems. One problem is overhead for the user and another interoperability.

That the standard is not optimal, for some cases there are always better approaches, is taken into account, to avoid the other problems.

I can only speak for myself. I find it cumbersome that different programs produce different FEN's. This causes avoidable problems, and I prefer to use my time to deal with real problems.

I don't know if, for this example, it is appropriate not to populate the en passant target square field. There is a hidden complexity here.

You mention a potential reason for not following the FEN specification is to use the produced value to detect threefold repetition. Just in case, this is an example of hidden complexity. The value you are writing in the FEN field does not work to detect threefold repetition reliably. Maybe you want to give your approach a second thought.

[niklasf]

There are competing "standards" in this area: FEN, X-FEN, and the objectively* best one :smile:

With the original FEN, you cannot assume that positions are uniquely identified by their FEN, so X-FEN is generally viewed as a compatible extension. If you grant that, showing only fully legal en passant squares is also a compatible extension.

a notation for positions has no business requiring* useless information about the history.

[dlbbld]

That the information is "useless" in this narrowed sense is correct, but then the solution is to change the standard. By the way, to populate the field as in Lichess requires move generation, which is also a disadvantage.

So, if one uses the following FEN in the analysis board: 4k3/8/8/8/4p3/8/3PR3/4K3 w - - 0 32

After performing d4, we have Lichess 4k3/8/8/8/3Pp3/8/4R3/4K3 b - - 0 32 FEN and X-FEN 4k3/8/8/8/3Pp3/8/4R3/4K3 b - d3 0 32

The value by Lichess can be used to check position repetition, but I don't see that as a justification. The user will not use that. Bitboards are for that.

I prefer to keep things simple, and the FEN specification is simple, and I see no reason not to use it. There are only a few chess specifications, and especially for that, I find it essential to follow them.

For a first digression, ChessBase always sets the halfmove clock as zero when copying the position. Bug, or do they find this modified FEN is better for the user? If I copy the position from a game in the KBNvK endgame, I am interested in if a mate is possible within the fifty-move rule. Modifying the FEN does not help.

For a second digression, I want to mention that there is a slightly different behaviour validating the en passant target square field and the castling field in the board editor.

For example, in the board editor, when the following value is entered in the FEN field: 4k3/8/8/8/3Pp3/8/4R3/4K3 b - - 0 32

Now, one changes the en passant target square field to d3. The value does not change to "-" when the field refreshes, only when switching to the analysis board. Maybe the reason is that this requires move generation.

This is converse to validating the castling field. Here the value is corrected when the field is refreshed.

Maybe the reason is that validation requires move generation? Using the FEN specification would allow immediate correction with an algorithm not requiring move generation.

[dlbbld]

The only thing that I find a shortcoming in the existing FEN specification is to specify the en passant target square. This has caused a lot of confusion. A field instead named pawn two square advance and specifying the same is logically equivalent and would have avoided most of today's misunderstanding of the field.

[benediktwerner]

It's no use discussing this any further. The field is entirely useless in the cases where Lichess doesn't set it and makes no difference whatsoever. It certainly won't be changed just for standard conformance. Resetting the halfmove clock is a completely incomparable issue.

If you really think this is so important, feel free to implement it yourself and maybe it will be accepted then but there's no way in hell I'm going to waste my time "fixing" something so useless and irrelevant and I doubt any other Lichess dev will.

[dlbbld]

In my understanding, I don't call it a discussion, you don't like it that's it.