michiguel wrote:In addition, it means that Houdini in this game was used in "probe only at root" mode. If you probe in search, it is almost impossible that this bug will have a significant effect. I suggest that all engines that have a GTB probing code previous to 0.4 to be used with "probing in search" or whatever name the author gave for that feature.
How do you mean?
The root position is an EGTB position, no engine will ever perform any analysis other than consulting the TB to select the move with the shortest distance to mate.
I guess I was very unclear (an possibly wrong).
What you call "consulting the EGTB" means a hidden one ply search, which exposes the bug with no chance to recover (because you are at the root with a EGTB position). When you do not have that situation and you could encounter the position in a deeper search, is more difficult that you face a problem. That is because the search should stop at the previous ply (because it is also an EGTB position). That is what I mean. This is because ep "generating" moves are not captures that could transition from a non EGTB position to an EGTB position.
If the engine probes in search, most likely won't see any ep position at all. This is true. Maybe, during a game, the engine would avoid reaching positions like this at the root, rather than avoiding the bug itself. But I am not so sure now and I may be wrong.
The bug is exposed at positions in the root, when black is a pawn ahead in a KPKPP positions (KPPKP is fine), and black plays a move that white could capture ep. If you probe in search, In addition, the root position must have been the best position from previous searches. That may add an extra condition that could make reaching this problem more a bit more unlikely, but it is not guaranteed.
Anyway, the real solution is to download the bugfix.
In the position h7-h5 is clearly the best move if White doesn't know the en-passant rule