Quiescence Search questions

[AndrewShort]

I have some Quies() questions:

(1) Stat question:
For "nodes searched" stat, I count calls to AlphaBeta() and Quies() combined. But for "depth searched" stat, I presently ignore any further depth searched by Quies(). Suppose the 2nd to last iteration of iterative deepening hit ply 8 in AlphaBeta(), then went as far as 6 deeper during Quies() - for a total depth of 14, then the last iteration of iterative deepening hit ply 9 in AlphaBeta(), then went only 3 deeper during Quies() - for a total depth of 12. Seems like one could report a total depth searched of 9 (if you ignore Quies() depth) or 14 if you include Quies() depth. What do you do?

(2) For speed improvement, but at the risk of accuracy, one could not call Quies() (and just use Eval() instead) if you are in the middle of a reduced depth search invoked by your null move code. Does anyone do this, or is that too risky?

thanks!

[Dann Corbit]

I have some Quies() questions:

(1) Stat question:
For "nodes searched" stat, I count calls to AlphaBeta() and Quies() combined. But for "depth searched" stat, I presently ignore any further depth searched by Quies(). Suppose the 2nd to last iteration of iterative deepening hit ply 8 in AlphaBeta(), then went as far as 6 deeper during Quies() - for a total depth of 14, then the last iteration of iterative deepening hit ply 9 in AlphaBeta(), then went only 3 deeper during Quies() - for a total depth of 12. Seems like one could report a total depth searched of 9 (if you ignore Quies() depth) or 14 if you include Quies() depth. What do you do?

Most people just report the main search depth and not quiescent depth. But you may consider that as part of your selective search and return the additional search dept as selective depth if you so choose (it may make sense to do that if you have an elaborate quiesce function). From the UCI specification, we have this:

* depth
search depth in plies
* seldepth
selective search depth in plies,
if the engine sends seldepth there must also be
a "depth" be present in the same string.

(2) For speed improvement, but at the risk of accuracy, one could not call Quies() (and just use Eval() instead) if you are in the middle of a reduced depth search invoked by your null move code. Does anyone do this, or is that too risky?

thanks!

Usually, it applied even to the main search, but this idea is called Lazy Eval:
http://members.home.nl/matador/chess840.htm#LAZY%20EVAL

If you apply these strategies only to the quiesce portion, you might call it "skimpy eval" or something to distinguish it from the usual lazy eval.

[Zach Wegner]

(1) Stat question:
For "nodes searched" stat, I count calls to AlphaBeta() and Quies() combined. But for "depth searched" stat, I presently ignore any further depth searched by Quies(). Suppose the 2nd to last iteration of iterative deepening hit ply 8 in AlphaBeta(), then went as far as 6 deeper during Quies() - for a total depth of 14, then the last iteration of iterative deepening hit ply 9 in AlphaBeta(), then went only 3 deeper during Quies() - for a total depth of 12. Seems like one could report a total depth searched of 9 (if you ignore Quies() depth) or 14 if you include Quies() depth. What do you do?

I use the absolute deepest depth search, including qsearch.

(2) For speed improvement, but at the risk of accuracy, one could not call Quies() (and just use Eval() instead) if you are in the middle of a reduced depth search invoked by your null move code. Does anyone do this, or is that too risky?

Don't do this at all, way too risky. In a modern chess program, a vast amount of searches are somewhere below a null move. The quiescence search adds a huge amount of stability by only evaluating quiet positions.

Additionally, some engines, like mine, rely on checks in quiescence to find threats under a null move, instead of limiting the depth to which null move is used. You can't do that when you are just evaluating...

[bob]

I have some Quies() questions:

(1) Stat question:
For "nodes searched" stat, I count calls to AlphaBeta() and Quies() combined. But for "depth searched" stat, I presently ignore any further depth searched by Quies(). Suppose the 2nd to last iteration of iterative deepening hit ply 8 in AlphaBeta(), then went as far as 6 deeper during Quies() - for a total depth of 14, then the last iteration of iterative deepening hit ply 9 in AlphaBeta(), then went only 3 deeper during Quies() - for a total depth of 12. Seems like one could report a total depth searched of 9 (if you ignore Quies() depth) or 14 if you include Quies() depth. What do you do?

Just report the iteration number, which is the nominal search depth reached on all branches (ignoring reductions and extensions and q-search).

(2) For speed improvement, but at the risk of accuracy, one could not call Quies() (and just use Eval() instead) if you are in the middle of a reduced depth search invoked by your null move code. Does anyone do this, or is that too risky?

thanks!

Way risky. The last move will _always_ be a capture since it does not get refuted. The call to Evaluate() will be based on a position where (say) white just played QxN, and is a piece up, where the next move would be PxQ leaving white totally lost... but the eval says "won"...