setboard 3b4/7k/6p1/4PpK1/5P2/8/8/8 w - f6 0 2
d
+-----------------+
| . . . b . . . . |
| . . . . . . . k |
| . . . . . . p . |
| . . . . P p K . | Castling:
| . . . . . P . . | ep: f6
| . . . . . . . . |
| . . . . . . . . |
| . . . . . . . . | [White]
+-----------------+
analyze
0-1 {Gaviota says Black mates}
A check by a piece can never be defended by an en passant capture or a pawn capture for that matter. So, a safe optimization is to ignore them when a check evasion is generated. So, Gaviota thinks it is mate.
Making some optimization that assumes the rules of chess are being followed is perfectly valid in my opinion. It's a bit like invoking undefined behavior (http://en.wikipedia.org/wiki/Undefined_behavior) in C++, where the compiler might use an optimization assuming that your code complies with the standard, and if your code doesn't then it is allowed to do whatever it does, including crashing, going into an infinite loop or deleting every file in your filesystem.
Perhaps the UCI specification should be explicit about the kinds of things that trigger undefined behavior by complying engines and GUIs.
I agree it would be nice if the UCI protocol would standardize basic move inputs. However no one prevents a programmer to just add it as an additional command feature.
Accepting moves in LAN was one of the first things I added to the iCE command list because it simplifies my life.
I just don't see the need for doing much retro-analysis for inputting a position. To do a good job would require proving that the input position could be somehow traced to the initial array. No one has ever provided a solution or this, although it might be possible.
tpetzke wrote:I agree it would be nice if the UCI protocol would standardize basic move inputs.
It would be nice if the UCI protocol used SAN moves and not the bulky, hard-to-read e2e4 c7c5 g1f3 d7d6 coordinate notation which went out of style forty years ago.