TalkChess.com

SMIRF wrote: The moment when the decision is made to call quiescence(), then only (in major cases) material exchanges should be investigated and not quiet moves. For me it does not seem to make sense, to ignore possible fluctuations whithin possible quiet moves, but to take those from captures into the evaluation.

My idea is, to use the detail evaluation from the root of quiescence and use it approriately through the whole quiescence search +/- , because any more precision would be an illusion. Moreover it could change the possible outcome, when the alpha-beta window later would be modified and the same node would be evaluated a second time, and fluctuating sub node detail evaluations would lead to different cuts.

I still don't understand.

Assuming that you have a standard iterative deepening loop where the search is recursed until some depth D. Once you reach depth D you evaluate the leaf node and back up the score.

How do you evaluate it? Simply returning static eval is inaccurate if there is unresolved tension in the position, so you call the quiescence search function to resolve the tension. At each node in the quiescence search you call the static evaluation function, so I don't understand "use the detail evaluation from the root of quiescence and use it approriately through the whole quiescence search +/- , because any more precision would be an illusion". The static evaluation at the beginning of QS is likely inaccurate.

As for ignoring improvements due to possible quiet moves: that's not the point of QS, that's what the next iteration of iterative deepening is for. QS is to avoid returning a good score in a position where you hang a queen.
There is an argument to be made that some "quiet" moves are not truly "quiet" in that making them could cause a huge swing in score (king-safety is a likely candidate). If you have a reliable way to detect those, then you can certainly include them in QS, and it will be more accurate. Whether it's better depends on whether the increased cost of evaluating the node is offset by the improved accuracy of QS, bearing in mind that iterative deepening will find such moves eventually anyway.

SMIRF wrote: It could not be avoided, that possibly a not investigated non capture would lead to a better detail evaluation than the best quiescence path. Thus using detail evaluation within the quiescence search cannot lead to more precision.

Where am I wrong within my thoughts?

It seems to me you only need one counterexample? Think about a king capture in the early midgame which exposes the king in a way that the side with the exposed king would become mated soon. King safety evaluation will detect the danger and calculate a score drop that far exceeds the material gain from the capture. If you leave king safety evaluation out and only look at the material balance you will be very wrong in this case.

Of course there are situations of benefitting. But I doubt that it will always be. Here an argument was written, that captures tends to change detail evaluation more than non-captures. For me that currently seems to be the strongest argument until now, to make use of the detail evaluation. But nevertheless it does'nt seem to be precise.

I think it's always more precise too look at all aspects of the position after a capture move. After all you have to decide which capture sequence the best one. If you have f.i. two pawn captures for the side to move, one them leads to a pawn weakness like a double pawn, the other pawn capture does not, you want to know it, no?

Even in case the swing from detail evaluation would be very small, you still want to know it. If you have 2 equal captures, one of them leading to slightly better mobility score, you still want to know about the difference and propagate the best you can estimate back to earlier nodes.

As you say: for most capture exchanges that will hold, but not compared to all the also possible but ignored silent moves.

Probably that problem could not be solved to a cheap but precise solution ...

When the modern engines are near quiescence, they start doing a lot of things to save work. Reducing more, pruning more, even cluelessly (but statistically safe)... In fact we can say that they start quiescence a lot before entering the function that has this name.

And once in quiescence, they use all the possible tricks to return the sooner possible.

So they are really never very exact on their conclusions. The engines just try to clean the field to have an approximate idea.

We don't compare with silent moves in qsearch. This is not precise but it's the idea of qsearch to only quickly resolve the most tactical issues. There is a tradedown between speed and accuracy as so often in chess programming. Qsearch is not precise by design.

If I understood right, you want to try to save the detail eval score at the root node of qsearch, then minimax through qsearch nodes using material comparison only until all the captures are resolved and finally propagate the score back to the root of qsearch and merge it with the saved detail value. If this is what you want to try, then I just say that this is always more inaccurate than to use a complete evaluation everywere in qsearch. Besides it is much easier to code the standard way. The only question would be if the speed gain from doing this would outweight the newly introduced inaccuracy. I think no, and to be honest, I'm sure enough that I would not even try it.

I think You should really use detailed eval in quiescence search. The problem was known in the early days of chess programming. Suppose that Your engine gives some bonus for a rook on the seventh rank at the root of the quiescence search and that engine's advantage depends only on this single factor. The opponent, however, can play RxR. In this situation it is crucial that quiescence search knows that it can recapture RxR (good) rather than NxR (bad).