It seems to me that requiring the e.p. field in a FEN to be only present if there actually is a legal e.p. capture just puts a completely needless burden on the routine that converts board positions to FENs. No information is lost by putting a superfluous e.p. square. A possible reader for which the presence of an actual capture makes any difference almost certainly will have the intelligence and information to figure out for itself if the capture exists, if it wants to know that.
FENs are designed as a tool to make life easy. So I think the existing standard made the good choice.
Programmer bug hunt challenge
Moderators: hgm, Rebel, chrisw
-
- Posts: 27790
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
-
- Posts: 20943
- Joined: Mon Feb 27, 2006 7:30 pm
- Location: Birmingham, AL
Re: Programmer bug hunt challenge
Here's the reason it is bad: You have a position with a white pawn at e4 and no black pawns on the d or f file. If the last move was e4, you get an EP target of e3. If the last move was something else, the ep target would be blank. Yet the two positions are absolutely identical. Why should they have different FEN strings?hgm wrote:It seems to me that requiring the e.p. field in a FEN to be only present if there actually is a legal e.p. capture just puts a completely needless burden on the routine that converts board positions to FENs. No information is lost by putting a superfluous e.p. square. A possible reader for which the presence of an actual capture makes any difference almost certainly will have the intelligence and information to figure out for itself if the capture exists, if it wants to know that.
FENs are designed as a tool to make life easy. So I think the existing standard made the good choice.
Whatever program writes the FEN string has some responsibilities anyway. The 50 move counter. Castling status. So why not simply get the EP target right so that there is no ambiguity as presently exists???
-
- Posts: 27790
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: Programmer bug hunt challenge
Because it is easier and hurts no one. There exists no ambiguity: it is always fully clear from a FEN if ep capture is possible or not.bob wrote:Why should they have different FEN strings?
Writing the 50-move counter and the castling status is trivial, as they are supplied in the definition of the position. The last move is also available, and if not, there is no way to determine e.p. status. All that is totally trivial compared to figuring out if you are in-check after an e.p. capture. For that you have to know the rules of Chess and in effect include a full move generator. That is at a totally different diffciculty level.
-
- Posts: 20943
- Joined: Mon Feb 27, 2006 7:30 pm
- Location: Birmingham, AL
Re: Programmer bug hunt challenge
Who cares about the "difficulty level"? The position where one side has played e4 is identical with the position where he has not, if there is no EP possible. Yet now we have two different FEN representations of the _identical_ string. Which makes position comparisons more complicated than necessary. Chess doesn't have a "pseudo-legal move" concept. Neither should it have an ambiguous position description. Regardless of how complex it makes the code that produces the FEN string...hgm wrote:Because it is easier and hurts no one. There exists no ambiguity: it is always fully clear from a FEN if ep capture is possible or not.bob wrote:Why should they have different FEN strings?
Writing the 50-move counter and the castling status is trivial, as they are supplied in the definition of the position. The last move is also available, and if not, there is no way to determine e.p. status. All that is totally trivial compared to figuring out if you are in-check after an e.p. capture. For that you have to know the rules of Chess and in effect include a full move generator. That is at a totally different diffciculty level.
What business does a program that doesn't "know the rules of chess" have producing position descriptions? Does it not need to know about move legality, in check status and so forth?
-
- Posts: 27790
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: Programmer bug hunt challenge
Lzy people like me do!bob wrote:Who cares about the "difficulty level"?
For instane, if I want to transplant FEN I/O routines from one Chess program (like Joker) to completely different program (like microMax, or a tablebase generator) that have completely different routines for move generation, I would have to change a lot more. Drawing on the Chess knowledge of the host program needlessly increases the interdependence, and reduces the portability of the routine between programs.
If I would want to use a FEN routine in a Chess variant, with fairy pieces, I would only hav to change the list of allowed letters and their encodings. If I would have to test for legality, it would be a disaster...
-
- Posts: 27790
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: Programmer bug hunt challenge
Lazy people like me do!bob wrote:Who cares about the "difficulty level"?
For instane, if I want to transplant FEN I/O routines from one Chess program (like Joker) to completely different program (like microMax, or a tablebase generator) that have completely different routines for move generation, I would have to change a lot more. Drawing on the Chess knowledge of the host program needlessly increases the interdependence, and reduces the portability of the routine between programs.
If I would want to use a FEN routine in a Chess variant, with fairy pieces, I would only hav to change the list of allowed letters and their encodings. If I would have to test for legality, it would be a disaster...
-
- Posts: 4675
- Joined: Mon Mar 13, 2006 7:43 pm
Re: Programmer bug hunt challenge
My summary comment on these things is that Bob is right and the standard could be improved by saying that the en passant target square should be specified if and only if there is at least one valid en passant capture. (There could be two.)
Yes, it means that a FEN using program has to know about legality testing. That's a reasonable requirement, and it's already necessary for valid SAN generation.
Yes, it means that a FEN using program has to know about legality testing. That's a reasonable requirement, and it's already necessary for valid SAN generation.
Re: Programmer bug hunt challenge
It appears that some are asking for Fen 2. Fen 1 served us well but could care less of chess logic. It was not a program of chess but rather a tool to place pieces on a board. 100's of programs work well with Fen 1. Can Fen 2 simplify things for chess programmers, YES. Is it really needed? 100's of programs say NO.