Why Stockfish doesn't evaluate a position at leaf?

Code, algorithms, languages, construction...
Post Reply
grandsmaster
Posts: 9
Joined: Sun Aug 03, 2014 1:40 pm

Why Stockfish doesn't evaluate a position at leaf?

Post by grandsmaster » Sun Aug 03, 2014 1:45 pm

Isn't chess engine a deep-first search? In search.cpp in Stockfish, we have:

eval = ss->staticEval = evaluate(pos);
TT.store(posKey, VALUE_NONE, BOUND_NONE, DEPTH_NONE, MOVE_NONE, ss->staticEval);

This is not done at the leaf, but I've seen in other engines we only evaluate a position at the leaf of the tree and only pass the result back to the parent. Why does Stockfish attempt to evaluate every position before the leaf of the tree is reached? Sorry, I don't understand.

hyatt
Posts: 1242
Joined: Thu Jun 10, 2010 2:13 am
Real Name: Bob Hyatt (Robert M. Hyatt)
Location: University of Alabama at Birmingham
Contact:

Re: Why Stockfish doesn't evaluate a position at leaf?

Post by hyatt » Mon Aug 04, 2014 1:46 am

I don't think you looked at the code carefully enough...

Look at search.cpp, module name = qsearch(). It calls evaluate() right at the top, in case this is a leaf...

grandsmaster
Posts: 9
Joined: Sun Aug 03, 2014 1:40 pm

Re: Why Stockfish doesn't evaluate a position at leaf?

Post by grandsmaster » Mon Aug 04, 2014 2:14 am

I can see that qsearch() does the evaluation as expected. But my concern is in the main search function defined by

Value search(Position& pos, Stack* ss, Value alpha, Value beta, Depth depth, bool cutNode)

When I was reading the function, I see in step 5

// Step 5. Evaluate the position statically and update parent's gain statistics)

It evaluates the position statically without checking whether the search has reached the leaf nodes. In Crafty, you only do this evaluation in the qsearch which is also my expectation. What I don't understand is that why in step 5 of the main search loop in Stockfish, the engine attempts to evaluate the position without reaching the leaf nodes?? I have this concern because I see in other engines, this evaluation is done in the qsearch but the function we're talking about is not the qsearch!

H.G.Muller
Posts: 190
Joined: Sun Jul 14, 2013 10:00 am
Real Name: H.G. Muller

Re: Why Stockfish doesn't evaluate a position at leaf?

Post by H.G.Muller » Mon Aug 04, 2014 9:42 am

There can be many reasons why you want to know the static evaluation in inner nodes. You could for instance use it to decide about futility pruning, or whether the current branch deserves extra reduction, or whether you want to try null move. I do it in all my engines, and they also use it for calculating the delayed-loss bonus.

Leave nodes use the evaluation as actual score (stand pat).

hyatt
Posts: 1242
Joined: Thu Jun 10, 2010 2:13 am
Real Name: Bob Hyatt (Robert M. Hyatt)
Location: University of Alabama at Birmingham
Contact:

Re: Why Stockfish doesn't evaluate a position at leaf?

Post by hyatt » Tue Aug 05, 2014 5:22 pm

grandsmaster wrote:I can see that qsearch() does the evaluation as expected. But my concern is in the main search function defined by

Value search(Position& pos, Stack* ss, Value alpha, Value beta, Depth depth, bool cutNode)

When I was reading the function, I see in step 5

// Step 5. Evaluate the position statically and update parent's gain statistics)

It evaluates the position statically without checking whether the search has reached the leaf nodes. In Crafty, you only do this evaluation in the qsearch which is also my expectation. What I don't understand is that why in step 5 of the main search loop in Stockfish, the engine attempts to evaluate the position without reaching the leaf nodes?? I have this concern because I see in other engines, this evaluation is done in the qsearch but the function we're talking about is not the qsearch!

Again, look at the code. That call to evaluate is NOT used to return a score. This is used internally by the search. For example, if the current move improves the static eval, it reduces it less than if it hurts the static eval. The only scores that get backed up through the tree come from the qsearch() code, however...

There are versions of Crafty that do internal node evaluation in an attempt to improve move ordering for LMR (among other things). This is not something new and different, it has been done forever.

Post Reply