In today's environment ...

[Mike Sherwin]

... is it really an advantage to do a positional evaluation all the way out at the leaves? Wouldn't it be more efficient to switch to a material only search at some point?

[Tony P.]

Do you mean 'lazy evaluation'? I guess it's worth a try in an engine with a heavy eval, e.g. a neural net can be restructured in the BranchyNet fashion and retrained. The lazy approach seems inefficient in engines with lightweight evals where the time savings aren't big enough to compensate for the accuracy loss.

[Mike Sherwin]

What I mean is that if the engine is on let's say iteration 30 do a normal positional eval at depth let's say when depth remaining is 6 and then search the remaining depth with just a material only search then on return combine the two scores. A positional score 24 ply deep should still be very accurate. And then the remaining depth will just be concerned with tactics. But, if I'm wrong then I'm wrong?

[D Sceviour]

It is difficult to know what to do with the information that comes from a fast lazy evaluation. It should not be stored in the hash table. One way or another, the result has to be returned as a score. If it is inaccurate then in confuses the search because the results may be outside the bounds of the alpha-beta window demands. It is better to try a futility prune in the search to keep the window very large.

[Gerd Isenberg]

What I mean is that if the engine is on let's say iteration 30 do a normal positional eval at depth let's say when depth remaining is 6 and then search the remaining depth with just a material only search then on return combine the two scores. A positional score 24 ply deep should still be very accurate. And then the remaining depth will just be concerned with tactics. But, if I'm wrong then I'm wrong?

It was quite common in the past - pre-processing not only at the root, but the interior of the tree with some depth left to the horizon - see all the quotes in oracle and pre-processing. I guess due to search instability and evaluation discontinuity / TT issues it won't gain ELO in todays Stockfish like engines - but who knows.

[jdart]

The reason you do full eval at the leaves is that with alpha-beta, leaf scores in the PV get backed up all the way to the root.

However, pruning techniques such as SEE pruning and futility pruning effectively cut off nodes that lose heavily due to material-only eval.

--Jon

[towforce]

... is it really an advantage to do a positional evaluation all the way out at the leaves? Wouldn't it be more efficient to switch to a material only search at some point?

At a certain point, chess authors found that it was worth their while to start removing knowledge from the eval because the size of the search tree made it redundant. I think that material value only could take this principle to the extreme by not doing any evaluation at all! Each time a generated move removes a piece from the board, subtract that piece's value from the evaluation score, and then pass that score as a parameter to the next generated position. When it's time to return a value, simply return that value as the valuation.

No time whatsoever spent evaluating a position for the price of a tiny bit of extra time during move generation!

[Alayan]

Material eval is too wrong to be of any use.

There is one situation where skipping eval to just search nodes might be worthwile, and that's to find mate when down a lot of material, as pruning engine have trouble with them.

But just doing a "find short mates" extension to all leaves isn't going to cut it because it's too slow compared to normal search. At least for CPU engines, Leela could use some CPU cores for it without losing speed if using a GPU.

But if you find the right activation condition (e.g. high king danger advantage for a side that's down material), maybe it could help heavy-pruning engines to see more of these "sac material and mate a few moves later" lines quicker without sacrificing elo.

[Tony P.]

It is difficult to know what to do with the information that comes from a fast lazy evaluation. It should not be stored in the hash table.

The table could have separate fields for different stage evals, but that would increase the entry size. I'm not sure how big of an issue this memory inefficiency is, but it's another con for sure.