Futility Idea based on total score

[mjlef]

Here is another probably worthless idea. Assume your evaluation wants to save time (futility). Most programs use some kind of window against alpha/beta and the expected maximum change in eval due to smaller terms like mobility. Assuming the eval always does material imbalance things (like NN vs P), does it ever become safe to assume the smaller terms can just not be calulated when the estimated eval is say > value(rook) or <-value(rook)? In other words, at some point it seems progress will have to depend on raw material gain and not on mobility and king safety, etc.

[Edsel Apostol]

Here is another probably worthless idea. Assume your evaluation wants to save time (futility). Most programs use some kind of window against alpha/beta and the expected maximum change in eval due to smaller terms like mobility. Assuming the eval always does material imbalance things (like NN vs P), does it ever become safe to assume the smaller terms can just not be calulated when the estimated eval is say > value(rook) or <-value(rook)? In other words, at some point it seems progress will have to depend on raw material gain and not on mobility and king safety, etc.

They called it lazy evaluation.

It's a good idea if:
a: implemented correctly
b: you have a good material imbalance evaluation
c: your evaluation is too slow

I'm not a fan of this anyway, my evaluation is just simple and my material imbalance evaluation is not that good yet.

[mjlef]

Here is another probably worthless idea. Assume your evaluation wants to save time (futility). Most programs use some kind of window against alpha/beta and the expected maximum change in eval due to smaller terms like mobility. Assuming the eval always does material imbalance things (like NN vs P), does it ever become safe to assume the smaller terms can just not be calulated when the estimated eval is say > value(rook) or <-value(rook)? In other words, at some point it seems progress will have to depend on raw material gain and not on mobility and king safety, etc.

They called it lazy evaluation.

It's a good idea if:
a: implemented correctly
b: you have a good material imbalance evaluation
c: your evaluation is too slow

I'm not a fan of this anyway, my evaluation is just simple and my material imbalance evaluation is not that good yet.

Actually, this a different idea. All programs I have examined use comparisons with score estimates against the current alpha and beta bounds. If the estimated eval is well outside one of these bounds, it does the lazy eval. I am proposing adding a second condition. If the absolute estimated score is very high (like +5 pawns) or very low (like -5 pawns) then also do the lazy eval. It seems likely small scoring changes will be good enough to change the result of the game. I only know of one other program doing something like this, and I think it was a programming error, but maybe a good one!

[Edsel Apostol]

Here is another probably worthless idea. Assume your evaluation wants to save time (futility). Most programs use some kind of window against alpha/beta and the expected maximum change in eval due to smaller terms like mobility. Assuming the eval always does material imbalance things (like NN vs P), does it ever become safe to assume the smaller terms can just not be calulated when the estimated eval is say > value(rook) or <-value(rook)? In other words, at some point it seems progress will have to depend on raw material gain and not on mobility and king safety, etc.

They called it lazy evaluation.

It's a good idea if:
a: implemented correctly
b: you have a good material imbalance evaluation
c: your evaluation is too slow

I'm not a fan of this anyway, my evaluation is just simple and my material imbalance evaluation is not that good yet.

Actually, this a different idea. All programs I have examined use comparisons with score estimates against the current alpha and beta bounds. If the estimated eval is well outside one of these bounds, it does the lazy eval. I am proposing adding a second condition. If the absolute estimated score is very high (like +5 pawns) or very low (like -5 pawns) then also do the lazy eval. It seems likely small scoring changes will be good enough to change the result of the game. I only know of one other program doing something like this, and I think it was a programming error, but maybe a good one!

If that's the case, it may work but not for all cases. The times it is going to fail is when the range of the alpha beta window is in that (5+) and (5-) but it is already a won or a lost position anyway.

[mcostalba]

They called it lazy evaluation.

It's a good idea if:
a: implemented correctly
b: you have a good material imbalance evaluation
c: your evaluation is too slow

I'm not a fan of this anyway, my evaluation is just simple and my material imbalance evaluation is not that good yet.

I fully second you, I don't particular like it although we have a slow evaluation and perhaps some kind of lazyiness would be useful.

Main problem IMHO is that evaluation is non-linear and could have some spikes due to passed pawns or king safety, these "spikes" are detectable only with full eval, are not a lot, but when they happen they can completely change the evaluation score.

[MattieShoes]

Actually, this a different idea. All programs I have examined use comparisons with score estimates against the current alpha and beta bounds. If the estimated eval is well outside one of these bounds, it does the lazy eval. I am proposing adding a second condition. If the absolute estimated score is very high (like +5 pawns) or very low (like -5 pawns) then also do the lazy eval. It seems likely small scoring changes will be good enough to change the result of the game. I only know of one other program doing something like this, and I think it was a programming error, but maybe a good one!

I'm not sure how valuable that would be.

If you're up a rook, you've probably already won. If you haven't, you have to wonder why. It could have been an unsound sac. A full eval might catch the move that makes the sac unsound while a lazy eval might allow the engine to get itself into trouble.