disadvantages of lazy eval

[kaustubh]

What are the disadvantages of lazy evaluation , and if the time limit is less do the chess engines do lazy evaluation.

[Roman Hartmann]

What are the disadvantages of lazy evaluation , and if the time limit is less do the chess engines do lazy evaluation.

I don't think lazy eval has any disadvantages if it's properly done. In fact it should improve any engine if you only would be able to tell if this node is safe to do a LE instead of calling the quiescence search.

Doing LE in a already very shallow search because there is not much time left is probably rather risky so I think LE is usually only called after you have searched to some depth (at least that's what I always did when I was using LE).

Rightnow I don't use LE anymore as calling the QS is much easier than to identify positions where it's safe to do a LE. But if it's properly done like in Rebel or Pro Deo it seems to help quite a bit according to Ed Schröder.

best regards
Roman

[bob]

What are the disadvantages of lazy evaluation , and if the time limit is less do the chess engines do lazy evaluation.

You avoid doing parts of the eval that are slow, betting that those parts are not enough to bring the score back into the alpha/beta window. If you are right, you save the time this would take, but if you are wrong, you will overlook things.

[bob]

What are the disadvantages of lazy evaluation , and if the time limit is less do the chess engines do lazy evaluation.

I don't think lazy eval has any disadvantages if it's properly done. In fact it should improve any engine if you only would be able to tell if this node is safe to do a LE instead of calling the quiescence search.

Doing LE in a already very shallow search because there is not much time left is probably rather risky so I think LE is usually only called after you have searched to some depth (at least that's what I always did when I was using LE).

Rightnow I don't use LE anymore as calling the QS is much easier than to identify positions where it's safe to do a LE. But if it's properly done like in Rebel or Pro Deo it seems to help quite a bit according to Ed Schröder.

best regards
Roman

I do not follow. I do lazy evaluation and do not "choose to do LE rather than call quiesce()"... LE just avoids doing part of the eval if it appears to be pointless. For example, alpha=100, beta=150, and current material score is -900. If you are sure your eval can't come up with 1000 positional points of score, there is no need in wasting the computational time and you can just return alpha rather than the actual positional + material score...

[Cardoso]

Please correct me if I'm wrong:
I have the idea that lazy eval only works with an eval that only adds bonus not penalties.
To my knowledge lazy eval works like this: we have a margin (call it lazy_margin, wich represents the maximum positional score we can possibly have) and current piece-square score plus lazy_margin can't make it to alpha the we can return immediately in eval.

But if we do penalties in eval then lazy eval shouldn't be used right? Because we are subtracting points from the current score and by doing this our positional score might never get bigger than lazy_margin.
If our eval computes both black and white material/positional scores and if our positional scoring code also does penalties (negative scores) then it doesn't make much sense using lazy eval at all or does it?

Alvaro

[bob]

How can you not have penalties? scores for black have to have the opposite sign as scores for white, which would look like a penalty.

All you care about in implementing lazy eval is to know the range of positional scores the slow part of your eval can produce, and then when you notice the initial material score is too far outside the alpha/beta bounds for that positoinal score to bring it back in, you just don't do the work.

There are three approaches to this:

1. In Crafty, I keep up with the largest positional score I produce and use that as a trigger threshold.

2. In Cray Blitz, we actually calculated the min/max positional score for each piece type, then we could sum these up to know exactly how large or small a "slow eval" score we might see and use that.

3. Use a static value that testing shows is "big enough to be safe, small enough to provide a performance gain..."

[Tord Romstad]

You avoid doing parts of the eval that are slow, betting that those parts are not enough to bring the score back into the alpha/beta window. If you are right, you save the time this would take, but if you are wrong, you will overlook things.

The problem is that, at least in my program, the slowest parts of the eval are always by far the biggest ones. I've never been able to save any time by using lazy eval.

Tord

[bob]

You avoid doing parts of the eval that are slow, betting that those parts are not enough to bring the score back into the alpha/beta window. If you are right, you save the time this would take, but if you are wrong, you will overlook things.

The problem is that, at least in my program, the slowest parts of the eval are always by far the biggest ones. I've never been able to save any time by using lazy eval.

Tord

That can be a problem. For me the slowest thing I do is the piece-by-piece evaluaton that is done after pawns (which are hashed already) and passed pawns. The biggest contributors I have are pawn evaluations (excluding simple pawn scoring which is hashed, I am talking about passed pawns here) and king safety. But they pale beside the normal piece scoring which includes mobility evaluation and the like.

[Zach Wegner]

I don't think lazy eval has any disadvantages if it's properly done. In fact it should improve any engine if you only would be able to tell if this node is safe to do a LE instead of calling the quiescence search.

I don't agree.
1) Some engines, like mine, use an evaluation hash. This minimizes the effect of LE. LE also complicates the implementation, though that isn't too bad.
2) Consider the fail-soft instability problems in the recent thread. I need every evaluation to return an _exact_ score, regardless of the bounds, because it will affect the tree in places where there are different bounds.
3) It's pretty complicated to accurately determine the maximum positional score, and keep it up to date as the evaluation changes. In fact, it's impossible for most evaluations (Turing and uncomputability, anyone?). And if it is big enough to not have any errors at all, then you get practically zero benefit.

[Tord Romstad]

That can be a problem. For me the slowest thing I do is the piece-by-piece evaluaton that is done after pawns (which are hashed already) and passed pawns. The biggest contributors I have are pawn evaluations (excluding simple pawn scoring which is hashed, I am talking about passed pawns here) and king safety. But they pale beside the normal piece scoring which includes mobility evaluation and the like.

For me, the two biggest evaluation components are also king safety and passed pawns -- but these components rely upon the normal piece scoring, or at least the expensive parts of it. I need complete attack information for all pieces before I can evaluate king safety and passed pawns.

Tord