disadvantages of lazy eval

[bob]

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.

I don't follow #2. If you are doing alpha/beta right, then you are only interested in nodes where the alpha < score < beta... Anything outside the A-B window should work just fine whether you use beta or beta+N, since neither is an acceptable score... If you pass different bounds to the LE program, it should either (a) give the proper score or (b) give the appropriate bound if the score is <= alpha or >= beta, which ought to work just fine since you can't trust scores outside AB anyway.

[Tony]

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.

I don't follow #2. If you are doing alpha/beta right, then you are only interested in nodes where the alpha < score < beta... Anything outside the A-B window should work just fine whether you use beta or beta+N, since neither is an acceptable score... If you pass different bounds to the LE program, it should either (a) give the proper score or (b) give the appropriate bound if the score is <= alpha or >= beta, which ought to work just fine since you can't trust scores outside AB anyway.

And yet, I've noticed my effective branching factor going up, when using lazy eval.

Tony

[Roman Hartmann]

I was reffering to the LE and eval but somehow the QS got mixed in here as well here.

Probably because I used in the past the LE as well to decide if I should enter the QS at the horizon. If margin+LE didn't make it to alpha I didn't bother to call the QS.

Roman

[Zach Wegner]

I don't follow #2. If you are doing alpha/beta right, then you are only interested in nodes where the alpha < score < beta... Anything outside the A-B window should work just fine whether you use beta or beta+N, since neither is an acceptable score... If you pass different bounds to the LE program, it should either (a) give the proper score or (b) give the appropriate bound if the score is <= alpha or >= beta, which ought to work just fine since you can't trust scores outside AB anyway.

But I use fail soft. The evaluation that eval returns sets the upper bound on a score. You can just return alpha or beta from eval on a lazy cutoff, and it would still be correct, but then you lose most of the benefit of fail soft.

[bob]

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.

I don't follow #2. If you are doing alpha/beta right, then you are only interested in nodes where the alpha < score < beta... Anything outside the A-B window should work just fine whether you use beta or beta+N, since neither is an acceptable score... If you pass different bounds to the LE program, it should either (a) give the proper score or (b) give the appropriate bound if the score is <= alpha or >= beta, which ought to work just fine since you can't trust scores outside AB anyway.

And yet, I've noticed my effective branching factor going up, when using lazy eval.

Tony

That coule mean several things, including a margin that is too narrow. Mine hangs around 2 in the middle game and I have been using it forever... (the 2 is my effective branching factor in general).

[bob]

I don't follow #2. If you are doing alpha/beta right, then you are only interested in nodes where the alpha < score < beta... Anything outside the A-B window should work just fine whether you use beta or beta+N, since neither is an acceptable score... If you pass different bounds to the LE program, it should either (a) give the proper score or (b) give the appropriate bound if the score is <= alpha or >= beta, which ought to work just fine since you can't trust scores outside AB anyway.

But I use fail soft. The evaluation that eval returns sets the upper bound on a score. You can just return alpha or beta from eval on a lazy cutoff, and it would still be correct, but then you lose most of the benefit of fail soft.

That should not change the result of the search however, or there is a bug. Fail-soft promises to return a better bound for re-searches when they are necessary, but nothing else. I've not seen much benefit to fail-soft in all my testing, except when I experimented with mtd(f) where it is critical...

[Zach Wegner]

Fail-soft promises to return a better bound for re-searches when they are necessary, but nothing else.

I don't even use it to adjust the bounds for researches. I don't use aspiration windows, and I do researches for PVS even when the score returned is > beta.

The only benefit I get is from hashing. You get a better bound to store.

[bob]

Fail-soft promises to return a better bound for re-searches when they are necessary, but nothing else.

I don't even use it to adjust the bounds for researches. I don't use aspiration windows, and I do researches for PVS even when the score returned is > beta.

The only benefit I get is from hashing. You get a better bound to store.

For me, that was a very small benefit. It was more noticable at shallower depths where the score sort of "hunts" around iteration to iteration. But once I get to normal depths (16-19 or so) the score is not so unstable and it didn't make a difference. Most of the fail-soft is still in Crafty, with just one or two exceptions, as it was not much of a change to add it when it was brought up years ago...