Exactly. The generator takes into account the ep information, but it does not store it.wgarvin wrote:I'm still not sure if I believe that the way you describe will always work.michiguel wrote:En passant is not a problem. Advancing a pawn two squares was the origin of all problems when you think about it. Indirectly, it generated the problem of having en passant.Tord Romstad wrote:Thanks to all of you for your suggestions! Everything looks a bit ugly and awkward, but I suppose that's the nature of en passant captures. If we could travel back in time and persuade whomever invented the en passant rule to find some other hobby than chess, the world would be a better place -- at least for chess programmers.
Anyway, in Gaviota tablebases, I do not store ep at all. When probing a position with ep, the score is determined by the fact that the side to move can chose between the score of the position without the ep, or the score of the position in which the ep is captured (negative score and corrected by a ply). The side to move chooses whatever is best between those two options. The whole thing is hidden in the probing function. This implies an extra probe (hidden) that happens very rarely. This probing function is the same for both the calculation of the tablebases and the probing performed by the engine during play.
I think this is the easiest way to deal with it. The ugliness is hidden in only one function. This design does not allow the ugliness to spread all over the place and I do not believe it causes problems with performance.
Miguel
This came up before, and I haven't seen anyone explain why it would always work.
http://www.talkchess.com/forum/viewtopi ... ht=#266471
Yes, once you get into the situation with the EP capture possibility, a 1-ply search will resolve the correct value for that position. But what about the positions leading up to it? Imagine a situation where the positions leading up to the one with the EP square were considered won or lost, only because the tablebase generator didn't know about the EP capture possibility. e.g. where it believes that the player who double-pushes the pawn will force a win by that move (and would have eventually lost by making any other move). Except that, once he gets into that position, his opponent can make the EP capture and he can't actually win.
If there are any positions where this actually happens, it would result in the engine believing it could win until it sees the position with the EP square and then going... "oops"!
So I question whether you can truly know that your bitbase or tablebase is 100% correct, if you don't build the knowledge of en-passant into the tablebase generator. Even if there are no "problem" positions of this sort in the actual endgames, it might be nice to have a generator which could prove that, rather than just crossing our fingers and hoping for the best. I guess Nalimov's tablebases include enpassant, so maybe this question could be answered by scanning the data in them.
[Edit: Oh wait... I missed the part where you said that you do the same probe when generating the tablebases. That sounds like it should work properly. My gripe is with the idea that ignoring ep during generation, could be patched up using that 1-ply search in the engine.]
For the sake of accuracy I should say that you do not need a 1-ply search. You need to probe only an extra position and adjust the score. Conceptually it is like a 1-ply search for only one move (the ep capture).
It is conceptually easy to check TB's. You scan every single position, do a 1-ply search, get the score, and compare it with the one that is stored. If this passes, the information stored in the tablebases must be correct. Mine passes this test. In fact, I found many problems and bugs in this way during the development. In addition, I should say that there are many available statistics from Nalimov's that matches Gaviota's. At this point I feel pretty confident about the correctness of Gaviota's tablebases.
Miguel