doing lazy exit in eval or better not ?

[Engin]

since a a couple of time i am doing 2 lazy exits in eval, only one before with the margin of 200 before evaluate pieces and king at last, now i do on the top the same what crafty is do at start of eval with ther material only, it seems that this speed up the eval a lot, but on the other side i think it will be lost some information about the position each time.

if i am looking at fruit, SF code they never using lazy exit, but they eval are not slow too, why ?

now i am very confused and dont want what i decide to do is better, not using of lazy exit anytime ? or using it for speed ?

for me is speed not all time the reason for strength only, may without lazy the search can cutoff much of moves then ?

[Chan Rasjid]

since a a couple of time i am doing 2 lazy exits in eval, only one before with the margin of 200 before evaluate pieces and king at last, now i do on the top the same what crafty is do at start of eval with ther material only, it seems that this speed up the eval a lot, but on the other side i think it will be lost some information about the position each time.

if i am looking at fruit, SF code they never using lazy exit, but they eval are not slow too, why ?

now i am very confused and dont want what i decide to do is better, not using of lazy exit anytime ? or using it for speed ?

for me is speed not all time the reason for strength only, may without lazy the search can cutoff much of moves then ?

If you are SURE Stockfish does not do any lazy evaluation and never exit eval() early because score + margin <= alpha or score - margin >= beta, then it is best to follow Stockfish until we have the time to test - move to other things.

It seems to me lazy_evaluation with early exit in some manner of implementation is beneficial - after all pawns evaluation.

Rasjid

[Eelco de Groot]

since a a couple of time i am doing 2 lazy exits in eval, only one before with the margin of 200 before evaluate pieces and king at last, now i do on the top the same what crafty is do at start of eval with ther material only, it seems that this speed up the eval a lot, but on the other side i think it will be lost some information about the position each time.

if i am looking at fruit, SF code they never using lazy exit, but they eval are not slow too, why ?

now i am very confused and dont want what i decide to do is better, not using of lazy exit anytime ? or using it for speed ?

for me is speed not all time the reason for strength only, may without lazy the search can cutoff much of moves then ?

If you are SURE Stockfish does not do any lazy evaluation and never exit eval() early because score + margin <= alpha or score - margin >= beta, then it is best to follow Stockfish until we have the time to test - move to other things.

It seems to me lazy_evaluation with early exit in some manner of implementation is beneficial - after all pawns evaluation.

Rasjid

Stockfish used to have a speedy form of mainly material eval besides the normal eval. But it was dropped, mainly to make things less complex I think. I can only give some general thoughts on this, I think you can of course gain some depth with lazy eval in several forms but you also add some complexity to the code and you should not underestimate the benefit of having a single eval for literally every position you encounter.

When you mention

score + margin <= alpha or score - margin >= beta

, I'm not sure but does not the fact that you take alpha and beta into account to decide to stop evaluating, mean that not every position is evaluated with the same rules? If so, this is a form of dynamical evaluation, which I tried only once in Toga but never again. I think it is a bad idea in a chessprogram Not to be confused with any form of learning, but search is dependant on being able to measure very small differences in positions if these positions are very close together/very similar, and for this you need a uniform evaluation function across the whole search tree.

See also past discussions about changing the evalution function based on just the characteristics of the root position, this I think leads to similar errors because of non uniform evaluation especially if evaluations remain stored from one search to the next in the hash tables.

Just some musings on 'dynamical evaluation' , regards,
Eelco

[Daniel Shawul]

Engin,
You are ok as it is. I do it that way too and I believe it is the most natural place. Others do it "indirectly" through qsearch futilty pruning with very small margins. In the eval, you have options to decide how to smartly skip lazy eval by looking at different patterns eg. passed pawns, threats etc . One may argue you can still do this outside , but the eval is the natural place.

[Chan Rasjid]

since a a couple of time i am doing 2 lazy exits in eval, only one before with the margin of 200 before evaluate pieces and king at last, now i do on the top the same what crafty is do at start of eval with ther material only, it seems that this speed up the eval a lot, but on the other side i think it will be lost some information about the position each time.

if i am looking at fruit, SF code they never using lazy exit, but they eval are not slow too, why ?

now i am very confused and dont want what i decide to do is better, not using of lazy exit anytime ? or using it for speed ?

for me is speed not all time the reason for strength only, may without lazy the search can cutoff much of moves then ?

If you are SURE Stockfish does not do any lazy evaluation and never exit eval() early because score + margin <= alpha or score - margin >= beta, then it is best to follow Stockfish until we have the time to test - move to other things.

It seems to me lazy_evaluation with early exit in some manner of implementation is beneficial - after all pawns evaluation.

Rasjid

Stockfish used to have a speedy form of mainly material eval besides the normal eval. But it was dropped, mainly to make things less complex I think. I can only give some general thoughts on this, I think you can of course gain some depth with lazy eval in several forms but you also add some complexity to the code and you should not underestimate the benefit of having a single eval for literally every position you encounter.

When you mention

score + margin <= alpha or score - margin >= beta

, I'm not sure but does not the fact that you take alpha and beta into account to decide to stop evaluating, mean that not every position is evaluated with the same rules? If so, this is a form of dynamical evaluation, which I tried only once in Toga but never again. I think it is a bad idea in a chessprogram Not to be confused with any form of learning, but search is dependant on being able to measure very small differences in positions if these positions are very close together/very similar, and for this you need a uniform evaluation function across the whole search tree.

See also past discussions about changing the evalution function based on just the characteristics of the root position, this I think leads to similar errors because of non uniform evaluation especially if evaluations remain stored from one search to the next in the hash tables.

Just some musings on 'dynamical evaluation' , regards,
Eelco

First, more about Stockfish. It has an effective SEE and successful and aggressive pruning and reductions. So the chess tree that it searches is already vastly reduced and using any form of lazy-evaluation might do more harm than good - like pushing the statistics too far. A full evaluation gives a lower nps, but aggressive pruning/reduction could more then compensate giving a good nps. Incidentally, I think Stockfish and Robbolitto had the highest nps; now I think it is Houdini. It is unlikely any top program can increase its nps significantly through better codes or reducing its evaluator - it can only be 'this' small and not smaller to remain at the top. So the reported significant increase in nps of Houdi 1.5 could most likely be from new areas of pruning/reductions that others still do not do.

About lazy-evaluation, I am not too sure nor have I seen how others do it. It is said Robbolitto has a watered-down simpler version for evaluation of internal nodes only. My use of below-alpha and above-beta probably is from what I read how some do it. I don't have futility pruning within qsearch, so it seems above- beta laziness could be equivalent to futility within qsearch, but I have to think again.

The following is how I do lazy evaluation; it still allow my program to be stronger than the two weaker linux program I have, homer and hoichess; but it cannot yet match Gaviota, Herrman or Crafty - given nice weather it could sometimes win a game against them:-

Code: Select all

//j is now score from material+pst+imbalace_bonus + full_pawns_evaluation
//margin = 2 Pawns

#if LAZY_EVAL_BETA
    /* tigher margin at higher ply or xside winning */
    if &#40;j >= beta + max&#40;LAZY_EVAL_BETA_MARGIN - &#40;ply << 1&#41;
                        + &#40;beta <= -v2Pawn&#41; * (&#40;beta + v2Pawn&#41; >> 1&#41;, 0&#41;
       ) &#123;
        //cannot hash lazy eval
        evflag = FLAG_LAZY_EVAL_BETA;
        return &#40;j <= -2 || j >= 2 ? j &#58; 2&#41;;
    &#125;
#endif

#if LAZY_EVAL_ALPHA
    if &#40;j + max&#40;LAZY_EVAL_ALPHA_MARGIN - &#40;ply << 1&#41;
                - &#40;alpha >= v2Pawn&#41; * (&#40;alpha - v2Pawn&#41; >> 1&#41;, 0&#41; <= alpha&#41; &#123;
        evflag = FLAG_LAZY_EVAL_ALPHA;
        return &#40;j <= -2 || j >= 2 ? j &#58; -2&#41;;
    &#125;
#endif
  

I cannot yet comment on your point that evaluation has to be uniformly applied throughout the tree. It is too general a principle and not easy to understand. Still the only 'truth' in chess programming is testing. Currently I don't have the resources to do any testing, just two games each against my usual opponents.

Best Regards,
Rasjid

[Engin]

Engin,
You are ok as it is. I do it that way too and I believe it is the most natural place. Others do it "indirectly" through qsearch futilty pruning with very small margins. In the eval, you have options to decide how to smartly skip lazy eval by looking at different patterns eg. passed pawns, threats etc . One may argue you can still do this outside , but the eval is the natural place.

yes, i have to look at your source of Scorpio too how you doing lazy eval exit, you to moved first lazy eval exit after pattern eval i think, i tryed too but now i removed first lazy exit completly and used only one LE after patterns and pawn eval but before pieces and king eval, after some couple of playing games the results was not better, so i decide to remove the lazy eval complete from eval, i found now that the search is not slower then before but searching much deeper ?!, so i am understand that i bennefit from full eval that i get more prunning moves in search.

[Mangar]

Hi,

since a very long time Spike has lazy eval. IMHO there is a small amount of elo you can gain. You can compare the amount of lazy-eval calls giving other result than full-eval compared to the search window. (Example: lazy-eval <= alpha, full-eval > alpha). Then you are able to select bounds to make sure this nearly never happens.

There might be drawbacks. Example: an eval value < alpha might get higher in lazy eval if you add a constant factor to the evaluation function on lazy eval (cur_eval += cur_eval + margin < alpha ? margin : less_relevant_evaluation_terms()). In quiescense this may lead to less foreward pruning for capture moves. LazyEval + MaxGain(capture_move) might be more often > alpha than FullEval + MaxGain(capture_move).

So I suggest to give it some statistic tests to find a bound that works for you and save the statistic algorithm as you have to run it again for every relevant eval change.

But only try this if you have no other things to try any more.

Greetings Volker

[Daniel Shawul]

Engin,
You are ok as it is. I do it that way too and I believe it is the most natural place. Others do it "indirectly" through qsearch futilty pruning with very small margins. In the eval, you have options to decide how to smartly skip lazy eval by looking at different patterns eg. passed pawns, threats etc . One may argue you can still do this outside , but the eval is the natural place.

yes, i have to look at your source of Scorpio too how you doing lazy eval exit, you to moved first lazy eval exit after pattern eval i think, i tryed too but now i removed first lazy exit completly and used only one LE after patterns and pawn eval but before pieces and king eval, after some couple of playing games the results was not better, so i decide to remove the lazy eval complete from eval, i found now that the search is not slower then before but searching much deeper ?!, so i am understand that i bennefit from full eval that i get more prunning moves in search.

Well in that case you should go with full eval. Do you also have delta/fultility prunign in the qsearch ? If that is the case , then that is doing the job for you. Otherwise it just means that your eval is too fast already there is no need to use lazy eval. You should stick to what ever works for you I guess.
YMMV

[BubbaTough]

What works best is highly dependent on your eval. If your positional factors can never add up to higher than 2 pawns but is very time consuming, then obviously lazyeval can be helpful. If a single move can never effect positional factors more than 1 pawn, again, lazy eval can be your friend (though in a more complex form where you track changes of non-material factors). However, if you have huge positional factors (such as king safety or passed pawns) that can swing wildly on a single move in a way that is hard to describe with a simple condition check, then lazy eval can be harmful.

Thus, in my opinion, the best way to determine whether it is worth pursuing is not to look at top programs and copy their decisions, but to look at your own evaluation function, analyze the conditions under which it produces large positional value swings, and pursue a strategy on that basis.

-Sam

[Daniel Shawul]

What works best is highly dependent on your eval. If your positional factors can never add up to higher than 2 pawns but is very time consuming, then obviously lazyeval can be helpful. If a single move can never effect positional factors more than 1 pawn, again, lazy eval can be your friend (though in a more complex form where you track changes of non-material factors). However, if you have huge positional factors (such as king safety or passed pawns) that can swing wildly on a single move in a way that is hard to describe with a simple condition check, then lazy eval can be harmful.

Thus, in my opinion, the best way to determine whether it is worth pursuing is not to look at top programs and copy their decisions, but to look at your own evaluation function, analyze the conditions under which it produces large positional value swings, and pursue a strategy on that basis.

-Sam

I agree. I still have code to avoid lazy evaling when there are passed pawns , king in danger, or after queen captures. And also code to add in some positional terms from previous ply's eval (idea from Ed). I have done a lot of games with my two lazy margins and it always performed much better than not doing it. 30% lazy eval is typical in middlegames for scorpio. It used to be as high as 50% when I tried some idea where i do many lazy evals after null-move.

Daniel