Impossible position

[cms271828]

I set this position up:

[D]6bk/8/8/2Pp4/8/1K6/8/8 w - d6 0 1

Which basically put my king in check after the ep capture, but technically this position is unreachable, so is it best to assume this position will never be used, or to write code preventing the capture in this instance.

Any thoughts?

[micron]

Perhaps I'm missing something, but I don't see how that differs from any other discovered check. Unless you are writing a legal move generator, you don't need "code preventing the capture".
Robert P.

[jwes]

If you are writing a legal move generator and only want to allow reachable positions, then you only need to check for attacks that go through your pawn. I would put a check into your epd reading routine to make such positions can't be input.

[Sven]

I set this position up:

[D]6bk/8/8/2Pp4/8/1K6/8/8 w - d6 0 1

Which basically put my king in check after the ep capture, but technically this position is unreachable, so is it best to assume this position will never be used, or to write code preventing the capture in this instance.

Any thoughts?

Two different points are involved:

1) how to address the legality of ep captures,
2) how to handle FEN strings of unreachable positions.

Regarding 1), this is really no special case at all. It depends on your move generation strategy, as already mentioned by others in this thread. A legal move generator must check whether making the ep capture would put the own king into check while a pseudo-legal move generator can ignore this since legality will be checked only after really making a move during search.

Regarding 2), you are right that this position is unreachable with legal moves from any legal starting position. This will always be the case for ep capture situations like the one above in conjunction with diagonals (here a2-g8) but will not occur with horizontals, like here:
[D]7k/8/8/1KPp2r1/8/8/8/8 w - d6 0 1[/D]
The ep capture is illegal but the position is not unreachable because the previous move d7-d5 came from a legal and reachable position.

Now please check the following examples:
[D]rnbqkbnr/pppppppp/8/8/8/2B5/PPPPPPPP/RN1QKBNR w KQkq - 0 1[/D]
[D]4k3/8/8/8/8/P7/PP6/4K3 w - - 0 1[/D]
[D]4k3/2pp3p/7p/7p/7p/8/7p/4K2R w K - 0 1[/D]
[D]7N/5pnq/6p1/8/8/4b1kb/7p/7K b - - 0 1[/D]
and think about how to handle these. All are unreachable, too. Would you think that engines should usally reject such positions? The effort to achieve that is different:

- The first position *could* be adressed by a rule saying that "if a bishop is not on first rank then at least one of four pawns on same square color must have moved already".

- The second and third positions *could* be addressed by a rule that detects possible original squares for pawns and tries to identify contradictions. For instance the third position is unreachable because black pawn h2 must have started either on c7 or d7 based on analysis of all other black h-pawns but both are obviously impossible.

- The fourth position is difficult since a retro analysis would be required that detects that the predecessor position resulting from unmaking Kg1-h1 is unreachable, too, and the only other predecessor (unmake Kg2-h1) is illegal. The absence of other predecessor positions would be detected with a reverse move generator that also finds whether a piece on last rank (like Nh8 here) could be result of promotion.

As you can see, there is more or less retro analysis involved in many cases to detect whether a position is unreachable. What engines are usually doing is restricted to a set of typical consistency checks that can be done statically and "easily" (whatever that means). You are free, however, to put more effort into such checking, and of course it would not be "wrong" to do so. It is just a question of being effective, and a question of where to define the border. In your case above I would say that it is too special to put effort into it. It may be a matter of taste, though.

Sven

[hgm]

IMO pedantic error checking is a _very_ bad thing to have in any software. You would be doing a lot of work for no other reason than to prevent something that could have worked from working, decreasing the usefulness. I call that sabotage...

[Dann Corbit]

IMO pedantic error checking is a _very_ bad thing to have in any software. You would be doing a lot of work for no other reason than to prevent something that could have worked from working, decreasing the usefulness. I call that sabotage...

Consider the positions of Ventin Abillo. Lots of fun, and many are not legally achievable.

Consider FRC positions. Many engines will reject them but could play them cleanly if they understood the castling rules. And if I wanted to clean up an FRC pv with crafty's epdpfdr command, too bad. It will stop processing immediately.

While legality checks are nice if requested, they are likely to be annoying otherwise.

[Sven]

IMO pedantic error checking is a _very_ bad thing to have in any software. You would be doing a lot of work for no other reason than to prevent something that could have worked from working, decreasing the usefulness. I call that sabotage...

That does highly depend on the area of application, and also on the level of abstraction of a particular piece of software. Systems that are used for space flights, trains, cars etc. should be a lot more pedantic, for instance. And when writing library code that shall be usable in many different situations it is a good advice to clearly define preconditions at public interfaces of such a library, and check these conditions at runtime.

So pedantic error checking can be a good thing or a bad thing.

Sven

[hgm]

Yeah, like that Airbus plane crash in that air show in Paris, where the fly-by-wire software refused to obey the pilot's command to pull up, because it was outside the proper parameters for a landing procedure, and so flew straight into the trees...

Sorry sir, you cannot do that now, we are landing!

[Sven]

Yeah, like that Airbus plane crash in that air show in Paris, where the fly-by-wire software refused to obey the pilot's command to pull up, because it was outside the proper parameters for a landing procedure, and so flew straight into the trees...

Sorry sir, you cannot do that now, we are landing!

That is a failure of requirements analysis. Doing it properly would bring up a system spec with a well-defined use case describing exactly what the pilot *must* be able to send as a command and what not, so that there is no guessing about proper parameters and when they are "allowed". The key point is that the *software system* must not crash, whatever parameters are given from outside. And one of many things to achieve that is parameter checking. So don't mix up reasons for crashing planes and for crashing software.

Sven

[Dirt]

Removed space?
[D]6bk/8/8/2Pp4/8/1K6/8/8 w - d6 0 1

Stockfish and an old version of Toga crash analyzing it.