Implications of Lazy eval on Don Beal effect in Fail Soft

[Henk]

Is it true that lazy eval does not perform well in Fail-Soft ? And if so why doesn't that hold for futility pruning and isn't that a good reason to switch over to Fail-Hard ?

[bob]

Is it true that lazy eval does not perform well in Fail-Soft ? And if so why doesn't that hold for futility pruning and isn't that a good reason to switch over to Fail-Hard ?

I don't see why fail-soft or fail-hard would matter. Yes, lazy eval might not give you a value quite as far outside the A-B window as a straight eval, but alpha is good enough to cause a cutoff. I don't think fail-soft helps anything at all until you start to use mtd(f).

[Henk]

Is it true that lazy eval does not perform well in Fail-Soft ? And if so why doesn't that hold for futility pruning and isn't that a good reason to switch over to Fail-Hard ?

I don't see why fail-soft or fail-hard would matter. Yes, lazy eval might not give you a value quite as far outside the A-B window as a straight eval, but alpha is good enough to cause a cutoff. I don't think fail-soft helps anything at all until you start to use mtd(f).

Fail-Soft gives higher lower bounds and lower upper bounds. Why doesn't that help ?

[Evert]

Fail-Soft gives higher lower bounds and lower upper bounds. Why doesn't that help ?

I don't know if anyone really knows why. I do remember that Bob once posted some test results that showed it made little or no difference in Crafty, which is probably what he was referring to here as well.

I always use fail-soft, but that's more based on an intuitive feeling (a superstition, if you will) that it "should" be better than on any firm data that says it is. As far as I know it's no better or worse than fail-hard in practice.

[bob]

Is it true that lazy eval does not perform well in Fail-Soft ? And if so why doesn't that hold for futility pruning and isn't that a good reason to switch over to Fail-Hard ?

I don't see why fail-soft or fail-hard would matter. Yes, lazy eval might not give you a value quite as far outside the A-B window as a straight eval, but alpha is good enough to cause a cutoff. I don't think fail-soft helps anything at all until you start to use mtd(f).

Fail-Soft gives higher lower bounds and lower upper bounds. Why doesn't that help ?

Because anything >= beta or <= beta causes a cutoff. Doesn't matter how much above or below. If you use PVS as almost everyone does, 99.9% of the tree is searched with a bound alpha, alpha+1. Whether you get a backed up value of alpha+1 or alpha+1000 doesn't help a bit. The only benefit I have seen is in mtd(f) where a backed up value outside the window gives you a better estimate on how far to relax the bound that failed...

[Henk]

Is it true that lazy eval does not perform well in Fail-Soft ? And if so why doesn't that hold for futility pruning and isn't that a good reason to switch over to Fail-Hard ?

I don't see why fail-soft or fail-hard would matter. Yes, lazy eval might not give you a value quite as far outside the A-B window as a straight eval, but alpha is good enough to cause a cutoff. I don't think fail-soft helps anything at all until you start to use mtd(f).

Fail-Soft gives higher lower bounds and lower upper bounds. Why doesn't that help ?

Because anything >= beta or <= beta causes a cutoff. Doesn't matter how much above or below. If you use PVS as almost everyone does, 99.9% of the tree is searched with a bound alpha, alpha+1. Whether you get a backed up value of alpha+1 or alpha+1000 doesn't help a bit. The only benefit I have seen is in mtd(f) where a backed up value outside the window gives you a better estimate on how far to relax the bound that failed...

Aha. I only don't use PVS in QuiescenceSearch because I don't have a first best move there.

There are also some entries in hash that are used and cause early cutoffs.

[bob]

Is it true that lazy eval does not perform well in Fail-Soft ? And if so why doesn't that hold for futility pruning and isn't that a good reason to switch over to Fail-Hard ?

I don't see why fail-soft or fail-hard would matter. Yes, lazy eval might not give you a value quite as far outside the A-B window as a straight eval, but alpha is good enough to cause a cutoff. I don't think fail-soft helps anything at all until you start to use mtd(f).

Fail-Soft gives higher lower bounds and lower upper bounds. Why doesn't that help ?

Because anything >= beta or <= beta causes a cutoff. Doesn't matter how much above or below. If you use PVS as almost everyone does, 99.9% of the tree is searched with a bound alpha, alpha+1. Whether you get a backed up value of alpha+1 or alpha+1000 doesn't help a bit. The only benefit I have seen is in mtd(f) where a backed up value outside the window gives you a better estimate on how far to relax the bound that failed...

Aha. I only don't use PVS in QuiescenceSearch because I don't have a first best move there.

There are also some entries in hash that are used and cause early cutoffs.

Good first move doesn't mean a thing here. A narrower window will produce a cutoff quicker than a wider one, regardless of move ordering, assuming it remains the same for either window...
searching a null-window from the previous ply??? I would assume you use a null-window there as well???

I don't do the "PVS algorithm in q-search, but almost all q-search nodes are with a null-window because of where they are called from..

[Henk]

Is it true that lazy eval does not perform well in Fail-Soft ? And if so why doesn't that hold for futility pruning and isn't that a good reason to switch over to Fail-Hard ?

I don't see why fail-soft or fail-hard would matter. Yes, lazy eval might not give you a value quite as far outside the A-B window as a straight eval, but alpha is good enough to cause a cutoff. I don't think fail-soft helps anything at all until you start to use mtd(f).

Fail-Soft gives higher lower bounds and lower upper bounds. Why doesn't that help ?

Because anything >= beta or <= beta causes a cutoff. Doesn't matter how much above or below. If you use PVS as almost everyone does, 99.9% of the tree is searched with a bound alpha, alpha+1. Whether you get a backed up value of alpha+1 or alpha+1000 doesn't help a bit. The only benefit I have seen is in mtd(f) where a backed up value outside the window gives you a better estimate on how far to relax the bound that failed...

Aha. I only don't use PVS in QuiescenceSearch because I don't have a first best move there.

There are also some entries in hash that are used and cause early cutoffs.

Good first move doesn't mean a thing here. A narrower window will produce a cutoff quicker than a wider one, regardless of move ordering, assuming it remains the same for either window...
searching a null-window from the previous ply??? I would assume you use a null-window there as well???

I don't understand what it says. Good first move doesn't mean a thing where ?

In normal search I use PVS everywhere. Move ordering is important to prevent researches. If current window is a null window it is still important to apply a move that gives a cutoff as soon as possible. So move ordering is also important in a null window search.

Good move ordering is important everywhere in both normal search and QuiescenceSearch.

[bob]

Is it true that lazy eval does not perform well in Fail-Soft ? And if so why doesn't that hold for futility pruning and isn't that a good reason to switch over to Fail-Hard ?

I don't see why fail-soft or fail-hard would matter. Yes, lazy eval might not give you a value quite as far outside the A-B window as a straight eval, but alpha is good enough to cause a cutoff. I don't think fail-soft helps anything at all until you start to use mtd(f).

Fail-Soft gives higher lower bounds and lower upper bounds. Why doesn't that help ?

Because anything >= beta or <= beta causes a cutoff. Doesn't matter how much above or below. If you use PVS as almost everyone does, 99.9% of the tree is searched with a bound alpha, alpha+1. Whether you get a backed up value of alpha+1 or alpha+1000 doesn't help a bit. The only benefit I have seen is in mtd(f) where a backed up value outside the window gives you a better estimate on how far to relax the bound that failed...

Aha. I only don't use PVS in QuiescenceSearch because I don't have a first best move there.

There are also some entries in hash that are used and cause early cutoffs.

Good first move doesn't mean a thing here. A narrower window will produce a cutoff quicker than a wider one, regardless of move ordering, assuming it remains the same for either window...
searching a null-window from the previous ply??? I would assume you use a null-window there as well???

I don't understand what it says. Good first move doesn't mean a thing where ?

In normal search I use PVS everywhere. Move ordering is important to prevent researches. If current window is a null window it is still important to apply a move that gives a cutoff as soon as possible. So move ordering is also important in a null window search.

Good move ordering is important everywhere in both normal search and QuiescenceSearch.

The point was this: Whether you do a search with alpha, alpha+1, or alpha and alpha+100, the first move won't matter if it is the same in both of those cases. Almost all of the tree is searched with a null-window, which means this fail-soft/fail-hard stuff is not going to have any effect. If something is == alpha, it is a fail low, if it is < alpha, it is STILL a fail low. So it doesn't really do anything inside the search, except that when you fail high or fail low, you have a VERY rough estimate of how far that window needs to be relaxed. Commonly used in mtd(f), but doesn't do anything for normal search.

[Henk]

Is it true that lazy eval does not perform well in Fail-Soft ? And if so why doesn't that hold for futility pruning and isn't that a good reason to switch over to Fail-Hard ?

I don't see why fail-soft or fail-hard would matter. Yes, lazy eval might not give you a value quite as far outside the A-B window as a straight eval, but alpha is good enough to cause a cutoff. I don't think fail-soft helps anything at all until you start to use mtd(f).

Fail-Soft gives higher lower bounds and lower upper bounds. Why doesn't that help ?

Because anything >= beta or <= beta causes a cutoff. Doesn't matter how much above or below. If you use PVS as almost everyone does, 99.9% of the tree is searched with a bound alpha, alpha+1. Whether you get a backed up value of alpha+1 or alpha+1000 doesn't help a bit. The only benefit I have seen is in mtd(f) where a backed up value outside the window gives you a better estimate on how far to relax the bound that failed...

Aha. I only don't use PVS in QuiescenceSearch because I don't have a first best move there.

There are also some entries in hash that are used and cause early cutoffs.

Good first move doesn't mean a thing here. A narrower window will produce a cutoff quicker than a wider one, regardless of move ordering, assuming it remains the same for either window...
searching a null-window from the previous ply??? I would assume you use a null-window there as well???

I don't understand what it says. Good first move doesn't mean a thing where ?

In normal search I use PVS everywhere. Move ordering is important to prevent researches. If current window is a null window it is still important to apply a move that gives a cutoff as soon as possible. So move ordering is also important in a null window search.

Good move ordering is important everywhere in both normal search and QuiescenceSearch.

The point was this: Whether you do a search with alpha, alpha+1, or alpha and alpha+100, the first move won't matter if it is the same in both of those cases. Almost all of the tree is searched with a null-window, which means this fail-soft/fail-hard stuff is not going to have any effect. If something is == alpha, it is a fail low, if it is < alpha, it is STILL a fail low. So it doesn't really do anything inside the search, except that when you fail high or fail low, you have a VERY rough estimate of how far that window needs to be relaxed. Commonly used in mtd(f), but doesn't do anything for normal search.

What about the entries in transposition table. Don't you get more cutoffs in fail-soft when looking up positions in transposition table for they have better lower and upper bounds or is that effect negligible too.