zenpawn wrote:
Wider versus a qsearch without checks, sure, but if you don't limit checks to the first N-ply, then I don't see how it's not doing the same thing as check extensions.
The goal of the check extension is to mitigate the horizon effect by not terminating the search in the middle of a forced line.
The goal of quiescence search is to correctly evaluate the tension in a position by examining moves that resolve tension (captures; promotions); alternatively, the goal is to try moves that can cause big swings in the evaluation score, as a way of measuring he reliability of the evaluation. Checking moves can certainly meet those criteria, as can other quiet moves that are not so easy to identify.
Sven Schüle wrote:
In theory you would almost be right but that won't work in practice since it would result in an unmanageable tree explosion. It would search a much larger tree than with just check extension. The latter does not add checks and their subtrees, it just extends replies to checks which were already there.
So, are you saying check extensions are only applied once in a given branch? Otherwise, it would seem just as prone to tree explosion.
Not quite erin. Check extension in the main search you generally either extend the check by one ply or the evasion from a check by one ply, but not both and since the response to a check is not often going to be a check itself (and sequences of checks and counterchecks are quite finite in nature since they require setup discoveries for the most part), your depth remaining is necessarily still going to be declining towards zero, just half as fast as it otherwise would.
By contrast the scheme he suggested in qsearch where you don't allow standing pat in check AND try all checks is exploding since check-evade-check-evade-check-evade patterns can be far more indefinite.
Sven Schüle wrote:
In theory you would almost be right but that won't work in practice since it would result in an unmanageable tree explosion. It would search a much larger tree than with just check extension. The latter does not add checks and their subtrees, it just extends replies to checks which were already there.
So, are you saying check extensions are only applied once in a given branch? Otherwise, it would seem just as prone to tree explosion.
No, I am not saying this. Check extension is not really prone to tree explosion, compared to (unlimited) checks in qsearch, since the latter adds many useless checks and their evasions and possibly further useless checks, while the former only adds (forced) check evasions. Be aware that during a "realistic" tree search performed by a chess engine (not by a human!), most checks are silly and useless.
OK, I guess I've got this position on my mind, where a check evasion extension would give another ply and thus another chance for a check, which would cause another evasion extension and so on and so on.
zenpawn wrote:OK, I guess I've got this position on my mind, where a check evasion extension would give another ply and thus another chance for a check, which would cause another evasion extension and so on and so on.
Ah, I think I just got the difference; the extra ply is immediately used up by the evader. Correct?
extending by one ply just means not doing the normal deduction of a ply. so you're searching a node with remaining depth = 10. most child moves are searched with remaining depth = 9. extended checks still are called with remaining depth = 10. then on the evasion, all noncheck evasions (most of them) will be searched with depth = 9.
Equivalently, on nodes that are in check you could instead not reduce depth of all evasions. So the original node with remaining depth 10, delivers a check which is called with remaining depth 9. And then all noncheck evasions from that node are still searched with remaining depth 9.
Just don't do both and you should have no explosion problems.
Turns out some of the search tree explosion I always see (at least in the endgame) with check evasion extensions enabled was due to also having single-move extensions. If the latter extension is applied only when the former hasn't already extended the depth, the issue is largely mitigated.
