hgm wrote:Both work. The first is known as fail-hard, the other as fail-soft. When you use a hash table, fail-soft is more efficient, as it tehds to lead to tighter bounds on the moves, which then get stored in tha hash table.
Also adds a bit of instability, although I still use it. unstable != bad, just a pain at times when debugging or testing.
Ok, that's what I thought, as I'm occasionally seeing very strange (although very temporary) PVs. So I guess that's what happens with fail-soft when it affects a move at the root?
The reason I caught this is in this position from the WAC (#264):
r2r2k1/1R2qp2/p5pp/2P5/b1PN1b2/P7/1Q3PPP/1B1R2K1 b - -
Myrddin's output through the first half-second with fail-soft was this:
Obviously, that mate in 2 score for Black is just dead wrong.
So I changed it to fail-hard, and it doesn't happen any more.
Or would the above be caused by something else entirely?
Thanks to all who have contributed!
jm
The most notable thing I see, and not all that often, is a fail high, but then the resulting search fails low and you get no PV, or a partial PV. With normal PVS, and fail-hard, you simply get a ton of alpha, alpha+1 bound position entries in the hash table. If you shift the window slightly, none of those entries will help find a PV if the new bounds are slightly higher. But with fail-soft, you can still find a bount stored that is above any modified bound you use, and fail high. And then on the re-search you can't see deeply enough to get a real score.
The fail high is actually correct, but it looks odd to not get a PV back.
hgm wrote:Both work. The first is known as fail-hard, the other as fail-soft. When you use a hash table, fail-soft is more efficient, as it tehds to lead to tighter bounds on the moves, which then get stored in tha hash table.
Also adds a bit of instability, although I still use it. unstable != bad, just a pain at times when debugging or testing.
Ok, that's what I thought, as I'm occasionally seeing very strange (although very temporary) PVs. So I guess that's what happens with fail-soft when it affects a move at the root?
The reason I caught this is in this position from the WAC (#264):
r2r2k1/1R2qp2/p5pp/2P5/b1PN1b2/P7/1Q3PPP/1B1R2K1 b - -
Myrddin's output through the first half-second with fail-soft was this:
Obviously, that mate in 2 score for Black is just dead wrong.
So I changed it to fail-hard, and it doesn't happen any more.
Or would the above be caused by something else entirely?
Thanks to all who have contributed!
jm
The most notable thing I see, and not all that often, is a fail high, but then the resulting search fails low and you get no PV, or a partial PV. With normal PVS, and fail-hard, you simply get a ton of alpha, alpha+1 bound position entries in the hash table. If you shift the window slightly, none of those entries will help find a PV if the new bounds are slightly higher. But with fail-soft, you can still find a bount stored that is above any modified bound you use, and fail high. And then on the re-search you can't see deeply enough to get a real score.
The fail high is actually correct, but it looks odd to not get a PV back.
You should not see wrong scores, ever, unless they are the result of your program simply missing something due to lack of depth. If you produce a mate score it should never be wrong. You _might_ produce a mate score from a hash hit, and then lose it later if you happen to overwrite the critical hash entry. You should pick it back up once you get deep enough to see the mate in your search, although that is not guaranteed to happen.
hgm wrote:Both work. The first is known as fail-hard, the other as fail-soft. When you use a hash table, fail-soft is more efficient, as it tehds to lead to tighter bounds on the moves, which then get stored in tha hash table.
Also adds a bit of instability, although I still use it. unstable != bad, just a pain at times when debugging or testing.
Ok, that's what I thought, as I'm occasionally seeing very strange (although very temporary) PVs. So I guess that's what happens with fail-soft when it affects a move at the root?
The reason I caught this is in this position from the WAC (#264):
r2r2k1/1R2qp2/p5pp/2P5/b1PN1b2/P7/1Q3PPP/1B1R2K1 b - -
Myrddin's output through the first half-second with fail-soft was this:
Obviously, that mate in 2 score for Black is just dead wrong.
So I changed it to fail-hard, and it doesn't happen any more.
Or would the above be caused by something else entirely?
Thanks to all who have contributed!
jm
The most notable thing I see, and not all that often, is a fail high, but then the resulting search fails low and you get no PV, or a partial PV. With normal PVS, and fail-hard, you simply get a ton of alpha, alpha+1 bound position entries in the hash table. If you shift the window slightly, none of those entries will help find a PV if the new bounds are slightly higher. But with fail-soft, you can still find a bount stored that is above any modified bound you use, and fail high. And then on the re-search you can't see deeply enough to get a real score.
The fail high is actually correct, but it looks odd to not get a PV back.
The lack of a (complete) PV is probably due to a hash hit. I do not walk the hash table to derive the full PV.
That means you must have another bug, which is partly masked by using fail-hard.
If that mate score occurs reproducibly, you should not have much difficulty debugging where it came from, at such low depth. If that score comes from a hash hit, just let it print the address of the hash entry it used, and then put in code to dump the search tree that filled that hash entry to get the rest of the PV.
JVMerlino wrote:
Ok, that's what I thought, as I'm occasionally seeing very strange (although very temporary) PVs. So I guess that's what happens with fail-soft when it affects a move at the root?
No.
Or would the above be caused by something else entirely?
