adaptive lazy eval

[Rebel]

I want to propose an idea that might work for those who use lazy eval in the CPW way. I noticed that TOGA II 3.0 uses a margin of 2 pawns and what I remember from previous LE threads that's an often used value.

The whole idea of LE is a gamble, the 2.00 margin works quite well in quiet to not so quiet positions but when the board is on fire and large evaluation bonuses apply (king safety, passed pawns) that exceed the 2.00 margin largely then LE becomes unreliable.

Here is an idea to create a flexible LE margin that -- most of the time -- will be much lower than the 2.00 and higher when the board position actually demands it. And search can do (calculate) that in an elegant way.

3 positions, one quiet, one not so quiet, one explosive and the calculated LE margin is displayed after each 10,000 positions.

[d]rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR w KQkq -

average=30 | lazy_eval=80 (10.000)
average=29 | lazy_eval=79 (20.000)
average=28 | lazy_eval=78 (30.000)
average=28 | lazy_eval=78 (40.000)

...

average=30 | lazy_eval=80 (5.800.000)
average=30 | lazy_eval=80 (5.810.000)
average=30 | lazy_eval=80 (5.820.000)
average=30 | lazy_eval=80 (5.830.000)

Lazy Eval Margin 0.80 instead of 2.00

[d]rnb1kb1r/1p3ppp/p5q1/4p3/3N4/4BB2/PPPQ1P1P/R3K2R w KQkq -

average=57 | lazy_eval=107 (10.000)
average=63 | lazy_eval=113 (20.000)
average=75 | lazy_eval=125 (30.000)
average=73 | lazy_eval=123 (40.000)

.....

average=83 | lazy_eval=133 (5.400.000)
average=83 | lazy_eval=133 (5.410.000)
average=84 | lazy_eval=134 (5.420.000)
average=84 | lazy_eval=134 (5.430.000)

Lazy Eval Margin 1.34 instead of 2.00

[d]7r/1k2P2P/4p3/1pp5/8/2pp4/1n3PP1/R4K1R w - -

average=219 | lazy_eval=269 (10.000)
average=223 | lazy_eval=273 (20.000)
average=234 | lazy_eval=284 (30.000)
average=240 | lazy_eval=290 (40.000)

.........

average=263 | lazy_eval=313 (7.410.000)
average=264 | lazy_eval=314 (7.420.000)
average=264 | lazy_eval=314 (7.430.000)
average=264 | lazy_eval=314 (7.440.000)

Lazy Eval Margin 3.14 instead of 2.00.

Perhaps the good move (g4) is now found earlier because of the higher LE margin.

Code in the next post, need a coffee first.

[Rebel]

For each done position in EVAL we calculate the difference between the EVAL score and the incremental score we already maintain during search, usually the sum of the piece values on the board + their PST values. The difference tells us how much EVAL has added | subtracted to it, exactly what we want to know and the average of all EVAL's will become the flexible lazy eval margin PLUS a reasonable safety value, 0.50 in the example code.

Vars
static uint64 eval_sum;
static uint64 eval_count;
static int lazy_eval;

Start of search
eval_sum=0;
eval_count=1;

End of EVAL
x=abs(eval_score - incremental_score);
eval_sum+=x;
eval_count++;
lazy_eval=eval_sum / eval_count;
lazy_eval+=50;

[Michael Sherwin]

My very first attempt at a chess program in C had no evaluation at all. It also could not castle nor did it have en passant. I played it manually against Chessmaster 5000 in positions where CM could not castle. It actually did well against CM even achieving winning positions. Even though my engine was basically a material only searcher the moves chosen by it were not just based on material. It counted all the beta cuts in favor of the engine in the tree for each root move then chose among equal material moves based on the highest count of said beta cuts. It played bizarre yet beautiful moves. I am trying to motivate myself to continue that experiment.

[pedrox]

I recently tried to remove lazy_eval again from my engine (I also have eval cache), but I could not since the tests indicated that I lost something from Elo, I now do not remember well but I think at least 10-15 points.

In the opening and middle game I use a value of 225. In the transition from middle game to the endgame I used a value of 400 and in the endgame a value of 600.

I have tried your adaptive lazy_eval and it seems that in my case it gains something, in an engine test against itself it gained 20 points with an error of +/- 20. Possibly much less doing a good test against other engines but it looks good.

The only difference is that I only have incremental the material and the margin that sum to the lazy_eval instead of 50 was 16.

[Rebel]

The only difference is that I only have incremental the material and the margin that sum to the lazy_eval instead of 50 was 16.

It's quite well possible you don't need a safety margin at all, my 0.50 was just a wild guess, maybe the search produces a value that is just good enough, I guess it will different for each engine.

Can't use the algorithm myself since I am doing LE not in the CPW way.