Luis Babboni wrote:Sven Schüle wrote:
...
If none of the captures you try improve the score then the score is the static eval score
...
The evaluation is make after each capture or just, as in non QS search,after all posible consecutevely captures end?
I´d asume just after all possible captures, specially now that I know that QS nodes needed to be visited use to be similar in amount than non QS search nodes that is not what I guessed before starting think in it.
May be this is obviously shown in the code you posted but I still not undersntand it so much.
By the way, could be possible that if the engine is too slow the QS is not a good idea?
I´m still not sure if I did some bug but in the first test I did, the withoutQS version is far better than the withQS version. The problem seems to be that in 40/4 the without QS use to reach 6 or 7 plies depth while the withQS use to reach 2 plies less in the non QS search so miss some combinations that not have captures in its first/s 1/2 move/s.
To directly answer your question: during QS you call the evaluation at the beginning of each node.
The problem is understanding the concepts of tree search in general and here especially quiescence search (QS). I suggest that you try to take a completely different perspective. Currently you are thinking in terms of a large sequence of operations that has to be performed to find the desired result. It will become much easier when looking at it the right way.
We solve the problem of searching a tree of chess variations (to find the best move that our engine shall play) by decomposing it into smaller sub-problems. The top-level problem is: find the best move at the root node (and its score). Among the other sub-problems which also include generating moves, making and unmaking them (thus traversing edges of the tree), and evaluating a position, we have the full-width search of an arbitrary chess position (node) to a desired depth and the quiescence search of a node which we apply at those nodes where the remaining depth for a full-width search has become zero (and at all nodes within a QS subtree, of course). Each node can be a terminal node (= leaf node) or an intermediate node (or whatever you call it). Now try to only think of what has to be done *at the current node*. By making a move you visit a new node, and there you solve a new sub-problem, the result of which will (or may) be used after unmaking that move and thus returning to the parent node. But don't mix these views into one, only look at one node at a time.
(This is about "recursion". It is possible to do it differently but in the beginning it might be more difficult to understand.)
If you ignore QS for a moment then tree search is very simple: your best move at each node is the move for which searching its subtree returns the best score from your perspective (which is the worst score from the opponent's view).
By adding QS you add a new type of node: the QS node. What do you do at a QS node? Usually the same as at a full-width node: you want to get back the best move and the score (but I would ignore the "best move" part for now), and you get it by searching all subtrees (of capture moves). The difference to full-width search is, at each QS node you start by calling the static eval to get a minimum score from viewpoint of moving side.
There is more, of course (and again I left out alpha-beta in the beginning), but the first goal should be to get a feeling of how tree search works.