En passant problem in gaviota tablebases

[syzygy]

At least in theory this oversight (when it is present in the generator and not just the probing code) can result in incorrect table entries, namely if there is a position in which the only winning move is a double pawn move that brings the opponent in a position in which his only legal move is the (losing) ep capture.

I'm reasonably sure there do not exist such positions with 5 pieces, but there might exist one with 6 pieces. I have tried to construct one in the past, but I don't remember if I found one or not. I think there are at most a few candidates.

Maybe someone wants to give it a try and find such a position.

There is such a position (but with a checking first move):
[D]8/8/q7/k1K5/p7/8/1P6/7R w - - 0 1

Close, but in this case the oversight (incorrectly assuming that the ep capture is optional) does not lead to an incorrect evaluation. Black is lost with and without ep capture right, so a tb generator that looks at b2b4 and then incorrectly evaluates by looking at the position after axb3 and the position without ep right will still determine that white's position is winning.

So it seems unlikely that a position exists where such a bug results in incorrect 6-piece tables.

[Marek Soszynski]

Does this mean that every engine that implements Gaviota tablebases till now is buggy (uses the same probing code)?

Notwithstanding, the bug is extremely rare in practice, I suppose.

[syzygy]

Does this mean that every engine that implements Gaviota tablebases till now is buggy (uses the same probing code)?

Notwithstanding, the bug is extremely rare in practice, I suppose.

The positions on which the probing code fails are extremely rare, and it can only fail if that position (or rather, one ply before it) is reached on the board.

These positions cannot be reached during the search, because only positions immediately after a capture into a 5-piece position will be probed. (Unless the engine has an unusual probing policy.)