Alessandro Scotti wrote:In some engines the behavior at d=0 is different from d=-1, e.g. by allowing checking moves in the first case.
OK, but even in engines where this is the case, that would have no impact on futility. That the opponent might do extra moves in reply to a d=1 move, which he cannot do on a d=0 move, can only make the d=1 move even worse. Certainly no need for a larger safety margin.
But you don't do futility in expectation of a refuting move, but because of the expected eval. And the eval will not be any better for the fact that the opponent can check. (Or if it will be, that is unlikely to be different at d=0 and d=-1.)
hgm wrote:A move that is futile at d=0 is just as futile at d=1, as the opponent is allowed to react to it in the same way. (In both cases you will get a d=0 reply.)
In some engines the behavior at d=0 is different from d=-1, e.g. by allowing checking moves in the first case.
I do not see how it is relevant.
In the case of movei I may allow checks also at depth=-1 but not at depth=-2(practically I have positive numbers and the qsearch get depth parameter)
We need to see examples when a move is futile at depth=0 but is not futile at depth=1.
checking moves are excluded in the first place and if we do not talk about checking moves then I do not see a situation when it can happen.
- King in check
- Giving a check
- Captures
- pawns that move to the 7th (2th) row.
Furthermore (and this is crucial) you must have some kind of solution that deals with big evaluation scores (such as a 8.00 bonus for a pawn outside of the quadrant in a pawn-ending, or huge evaluation scores for passers and king-safety) that tend to exceed the margin.
I remember it gave me a 25% speed improvement with hardly any holes the time I implemented futility pruning. Not bad....
Ed
I wonder if you tried smaller values.
Note that from experience it seems that the it may be better to use more pruning for games relative to test suites so maybe you can increase the playing strength of prodeo if you decide to be ready to take more risks.
The experience that I talk about is not only my experience.
It seems clear that Rybka1.2 got worse in test suites relative to the first beta version because of doing more pruning when it got better in games.
Several times you said "... it started out well .... it lost much in the last
100 .... "
Are you sure your sparring partners don't have automated learning?
I know its an obvious question but that happened to me a few months
ago. An engine that wasn't documented to have learning did have
learning. Checking the file time stamps was the clue to find it.
- King in check
- Giving a check
- Captures
- pawns that move to the 7th (2th) row.
Furthermore (and this is crucial) you must have some kind of solution that deals with big evaluation scores (such as a 8.00 bonus for a pawn outside of the quadrant in a pawn-ending, or huge evaluation scores for passers and king-safety) that tend to exceed the margin.
I remember it gave me a 25% speed improvement with hardly any holes the time I implemented futility pruning. Not bad....
Ed
I wonder if you tried smaller values.
Note that from experience it seems that the it may be better to use more pruning for games relative to test suites so maybe you can increase the playing strength of prodeo if you decide to be ready to take more risks.
The experience that I talk about is not only my experience.
It seems clear that Rybka1.2 got worse in test suites relative to the first beta version because of doing more pruning when it got better in games.
Uri
I have a parameter to tune the futility margins [Futility = 100], I have tried lower percentages without improvement. But maybe I should retry since the last time I tested Futility Pruning is certainly 5 years ago or so. It could be very well the case that on modern hardware a lower percentage would turn out to be an improvement.
