Not so fast. Suppose I find a repetition that occurs a couple of plies deeper in the tree, and when I get back to this point I store score=draw. But when I reach this position again, except that now an ep capture is possible, I again would use that entry that says "draw" and it would be wrong.diep wrote:Let's refute all your arguments 1 by 1.bob wrote:I am not sure I buy that. If the positions are not equal because of en passant capture possibility, then they are simply different. One might lead to a draw by repetition the other will not. EP captures are sometimes subtle "get out of check" moves as I discovered when writing my legal-move generator for Crafty years ago. I would not use an entry for a "different position" with respect to EP status, castling status or side-on-move any more than I would use an entry for a position that is different because pieces are on different squares...diep wrote:Actually it goes even further.
Let's consider 2 positions P and P'
In P we can capture en passant
In P' we cannot capture en passant
If we're in P then for transposition table next is true:
If we normally spoken would get a cutoff based upon P'
so the only criterium that limits us is the fact that en passant is
possible here then there is 2 possibilities
a) in case of lowerbound cutoff we can give that
b) in case of upperbound or truebound score in hashtable,
we need to only calculate the value of the en passant move
and then can maximize the score with the value from hashtable
and return that
If we're in P' and in hashtable we find a positoin P that's based upon
en passant, then in case of:
a) upperbound we can safely give a cutoff
b) lowerbound or truebound we can give a cutoff in case the best
move is not an en passant move
Vincent
a) repetition: how would this go wrong now when it didn't already go wrong in your regular search? It is a total different problem unrelated to this.
No you can't. A position where an EP is possible is different from one where it is not possible. My early legal move generator had this bug and did not recognize the fact that an EP capture can be a check evasion move because the pawn moves to an odd square that blocks the check where without the ep possibility, the check could not be blocked. Both Kim Commons and Brian Hartmann found this bug in an early version of Crafty playing on ICC. It was not that common, but it was happening in more than one game out of a hundred until I fixed it.
b) extension problem: You can prove with natural induction (0,1,n+1..n) for all cases that this goes ok.
c) we're speaking just about en passant here, not about castling. However what holds true for en passant also holds true for castling.
Nice hand-wave, but the two positions are not equal. We already have this problem surfacing with 5-piece endgame tables and it does make a difference.
I'm not going to knowingly use something that has an obvious flaw I can see. There are too many other places to go wrong unintentionally, to risk adding to this by ignoring ep or castling. Shoot, why not ignore side to move as well as you will get more hash hits. Particularly in fine 70.
d) whether effectively it speeds up our software in openingsphase remains to be seen. I guess we all agree about this. In a program like diep using a lot of cycles a node i have of course more headroom for algorithmic tricks and enhancements than you've got in crafty which is approaching the 1000 cycles a node. As comparision the 32 bits engines out of 90s already at 'crappy' p5 processors were underneath 1000 cycles a node, just to show how efficient those engines were, despite inline intrinsics and the best possible compiler support someone could wish on this planet, as crafty was in specint.
Yet it remains a fact that the en passant capture usually is giving a cutoff when it is possible. Secondly for all that administration and extra code, only under the CONDITION we don't have this position stored yet AND we have it stored with other properties at the same search depth, THEN our code gets triggered.
Normal odds for a transposition entry that gives a success is roughly 4% to 5% (at non-qsearch depths) in most chess engines. So for that 1 in 20 odds for just a few positions in the search tree, we're doing all that administration here.
If we'd be searching 100 plies deep that would be fantastic of course, yet we aren't.
I'm producing later some outputs of diep where i ignore en passant completely in hashtable (yet i generate it in search) to see whether it has a potential to reduce a lot of nodes in openingsposition at a tad bigger search depth single core.
Idea is that if this reduces a lot of nodes and/or search time, that it's worth taking a better look at this.
Vincent