smrf wrote:If the evaluation is depending on the path through wich a current position has been reached, a reuse of cached evaluation values found after different paths would end in false results. The difference may be not that big, but noticeable. Especially at multithreaded engines this effect partially is reason for randomly raising different results for identical start positions.
Who would design a "positional evaluator" that uses path information? I don't do this in Crafty, except for the minor case of losing castling rights which I account for in hash signature calculations.
Also anyone depending on cached values when they are invalid is asking for trouble, so don't do that in the first place... Done reasonably this is not an issue for any program I have looked at.
bob wrote:But what kind of transposition table inconsistencies are you seeing? I can't see how recapture extensions would be any different than any other type of extension with respect to the hash table information...
If something is a recapture or not depends on the path to the node, in particular on the preding move. E.g.
[d]2kr4/4p3/5q2/4Q3/8/8/7P/4R1K1 w - - 0 1
after 1. Kh1, Rg8 2. Qxf6, then 2. ..., exf6 would be a recapture, but after 1. Qxf6, Rg8+ 2. Kh1, the same position would be reached without 2. ..., exf6 being a recapture. So there would be two distinc search trees for the position after white's second move, one extending exf6, the other not, competing for the same hash entry. As you would probably meant toe xtend here, the recapture extension could be made ineffective by trying the second branch first, and then getting a hash hit on it during the search of the first branch.
Why is that not a recapture. In Cray Blitz, and old Crafty versions, and Hitech, and Belle, etc, we all used the idea of "restoring the material balance is a recapture". Some made it more restrictive as I did later on, but I don't see why you would want to treat one of those differently than the other, since they lead to the exact same position... with the exact same tree below them.
bob wrote:Why is that not a recapture. In Cray Blitz, and old Crafty versions, and Hitech, and Belle, etc, we all used the idea of "restoring the material balance is a recapture".
I guess it depends on how you define it. uMax 4.0 defined a recapture as capturing the piece that moved on the ply before.
Your definition seems to have the undesired property that when you are a Pawn behind, recapturing a piece after an equal trade does not count as a recapture, as it does not resore the material balance, but still leaves a gap of a Pawn. And it seems illogical to make the treatment of such a capture dependent on if you happened to be behind or ahead. This is why I prefer to drop the concept of 'recapture' altogether, and use the more objective 'good capture': any capture that wins material.
bob wrote:... Who would design a "positional evaluator" that uses path information? I don't do this in Crafty, except for the minor case of losing castling rights which I account for in hash signature calculations. ...
Maybe I failed in making the question sufficient clear. My remark is not targeting evaluation functions. It is talking about different to be analysed subtrees, depending on which way the to be inspected node has been entered. This effect moreover is present in weaker form for nodes entered with different alpha beta window, where e.g. the nullmove pruning might reshape the subtrees very differently.
Nevertheless this all is going more and more distant to my initial question, whether deepening caused by promising trajectories has been experienced to be beneficial. H.G.Muller argued (as i understood), that this could lead into subtrees the opponent never would like to enter at all and thus would be irrelevant, and so additionally maybe time consuming.
hgm wrote:Your definition seems to have the undesired property that when you are a Pawn behind, recapturing a piece after an equal trade does not count as a recapture, as it does not resore the material balance, but still leaves a gap of a Pawn. And it seems illogical to make the treatment of such a capture dependent on if you happened to be behind or ahead. This is why I prefer to drop the concept of 'recapture' altogether, and use the more objective 'good capture': any capture that wins material.
The "material balance" isn't just the straight material balance, it's the material balance of the root node. So if you are a pawn down at the root, then there will still be a recapture extension.
If you lose a pawn between the root and the recapture, however, then there won't be one. The idea is that recaptures are delaying moves that can suffer from the horizon effect, while if you are already losing, then no delaying moves are needed.
bob wrote:... Who would design a "positional evaluator" that uses path information? I don't do this in Crafty, except for the minor case of losing castling rights which I account for in hash signature calculations. ...
Maybe I failed in making the question sufficient clear. My remark is not targeting evaluation functions. It is talking about different to be analysed subtrees, depending on which way the to be inspected node has been entered. This effect moreover is present in weaker form for nodes entered with different alpha beta window, where e.g. the nullmove pruning might reshape the subtrees very differently.
Nevertheless this all is going more and more distant to my initial question, whether deepening caused by promising trajectories has been experienced to be beneficial. H.G.Muller argued (as i understood), that this could lead into subtrees the opponent never would like to enter at all and thus would be irrelevant, and so additionally maybe time consuming.
I won't argue the point for anyone that writes an evaluation that operates like that, but I never have. My "positional evaluation" just evaluates a position, the only path-dependent part is whether or not castling rights were lost between the root and the endpoint, but I account for that in hashing so that I can recognize two identical positions where one was produced by castling and one was produced by "castling the hard way".
My evaluation doesn't depend on alpha/beta or anything else, so I don't see how/why one would write a program where this might be a problem
bob wrote:Why is that not a recapture. In Cray Blitz, and old Crafty versions, and Hitech, and Belle, etc, we all used the idea of "restoring the material balance is a recapture".
I guess it depends on how you define it. uMax 4.0 defined a recapture as capturing the piece that moved on the ply before.
Your definition seems to have the undesired property that when you are a Pawn behind, recapturing a piece after an equal trade does not count as a recapture, as it does not resore the material balance, but still leaves a gap of a Pawn. And it seems illogical to make the treatment of such a capture dependent on if you happened to be behind or ahead. This is why I prefer to drop the concept of 'recapture' altogether, and use the more objective 'good capture': any capture that wins material.
No. Read Berliner's paper on Hitech. The idea was to "restore the material value to what it was at the root." If you are running along a piece up, and then you capture a rook, when the opponent then captures a rook that is a recapture as it restores material balance. Not necessarily to zero, but to what it was at the root of the search. There are some tricks to deal with when the root move itself is a capture, but that is not hard to deal with...
I don't like the idea of extending "good captures" at all. The idea for the recpature extension was to avoid horizon effect issues where a capture is the most forcing move after a check, and requires an immediate recapture most of the time else the opportunity for the recapture disappears. A good capture appears to win material and is not a horizon effect type move at all.
But in any case, I removed recaptures quite a while back after lots of testing showed it did not help/hurt game results at all... In the days of 5-6-7 ply searches it seemed to be a good idea, but in the days of 16+ ply searches, not...
smrf wrote:Nevertheless this all is going more and more distant to my initial question, whether deepening caused by promising trajectories has been experienced to be beneficial. H.G.Muller argued (as i understood), that this could lead into subtrees the opponent never would like to enter at all and thus would be irrelevant, and so additionally maybe time consuming.
The only person I know of to pursue this path seriously is Sergei Markoff, inspired by Botvinnik. See the Botvinnik-Markoff Extension, which kind of applies here: http://chessprogramming.wikispaces.com/ ... +Extension
He also did things that were more in line with trajectories. There should be posts floating around in the old CCC archives.
Zach Wegner wrote:If you lose a pawn between the root and the recapture, however, then there won't be one. The idea is that recaptures are delaying moves that can suffer from the horizon effect, while if you are already losing, then no delaying moves are needed.
The loss of the Pawn at an early stage could be unavoidable. So you would really have to look at the score of the root node, rather than its material eval. But that of course creates the problem that it is not known yet when you search the first branch.
I wonder, though, how important all this is when you use null move. The latter is usually pretty good in dealing with horizon effect, as you need to waste two plies before you have shifted the horizon to where it was in the null-move search.
bob wrote:... My evaluation doesn't depend on alpha/beta or anything else, so I don't see how/why one would write a program where this might be a problem
The moment someone e.g. uses nullmove pruning he already makes his tree evaluation depending on the initial alpha beta frame. Of course, it is possible to completely ignore this, as it would be handled mostly. Nevertheless that problem exists. Reentering tree evalution with changed alpha beta window at a node reusing matching results stored inside a cache will errornously rely on the assumption that identical subtrees would be inspected. But that is definitely wrong.
