A question about Stockfish and LMR or other pruning...

[syzygy]

In any case, it does work and its not just random noise. I use it all the time to drive a good position to a winning position by finding better moves in less time!

And most likely (but this would have to be measured) it simply loses Elo.

[Uri Blass]

Yes it's possible in some cases that when you have to resolve a fail low/high, that searching from a lower depth with the deeper available hash info will resolve you a best line quicker and get through the new depth faster.

I've tried this once.. Reduce depth by one if there's a fail high/low at the root. It behaves a bit funny. Searchdepth going up and down looks a bit confusing, have to take a lot of precautions not to end up in never ending loops, causes a bunch of extra search instability and in a lot of cases you have to do the same amount of work anyway so yeah.. I quickly removed it.
A crude hackjob for something that should probably be more elegantly fixed in the search. (With smarter IID for example.)

I'm not talking about a reduction of a single ply since this is unlikely to produce much of a savings in time, especially at shorter time controls. Also, you can't have a never ending loop since you will run out of time. If you are doing the same amount of work anyway, it means you aren't using the right conditional trigger. Nothing more or less.

That is probably just random noise...

He says with a completely dismissive tone in his voice...

If it's just random noise than it wouldn't be repeatable from occasion to occasion. Therefore it's not JUST random noise!

History table values affect move ordering, and they change all the time. If you stop/re-start, you start off with different values than when you previously did the search. And as a result, you get different move ordering. LMR is sensitive to ordering and the shape of the tree can change dramatically due to this simple action. Hash table entries also affect move ordering (hash move is usually searched first) so you get yet another random change when you start over...

OK, lets consider the conditions when this might be useful. First, I don't use this technique unless one side has an advantage. Second, a move failing high isn't sufficient reason to use this technique. At a very minimum, a fail high must have occurred and a move change in the PV at a relatively high level, i.e. close to the root. How much of an advantage is needed for this to be useful is up for debate (25-50 centi-pawn?? of course higher is better here). I don't know how close the move change in the PV need to be to the root as I haven't tried to systematically test this. A rough guess is at least half the search depth and a third is probably better. e.g. on a 30 ply search if one or more fail-highs have occurred and a move change in the PV occurred at ply 10 (a third of the search depth) then its probably going to save time. The exact parameters would have to be determined by testing of course. This would be relatively easy to test in the SF testing framework I would think.

In any case, it does work and its not just random noise. I use it all the time to drive a good position to a winning position by finding better moves in less time!

Regards,

Forrest

I would like to see examples when it helps to change drawing moves to winning moves in less time(finding winning score in less time when you already found the winning move is not important).

[bob]

Yes it's possible in some cases that when you have to resolve a fail low/high, that searching from a lower depth with the deeper available hash info will resolve you a best line quicker and get through the new depth faster.

I've tried this once.. Reduce depth by one if there's a fail high/low at the root. It behaves a bit funny. Searchdepth going up and down looks a bit confusing, have to take a lot of precautions not to end up in never ending loops, causes a bunch of extra search instability and in a lot of cases you have to do the same amount of work anyway so yeah.. I quickly removed it.
A crude hackjob for something that should probably be more elegantly fixed in the search. (With smarter IID for example.)

I'm not talking about a reduction of a single ply since this is unlikely to produce much of a savings in time, especially at shorter time controls. Also, you can't have a never ending loop since you will run out of time. If you are doing the same amount of work anyway, it means you aren't using the right conditional trigger. Nothing more or less.

That is probably just random noise...

He says with a completely dismissive tone in his voice...

If it's just random noise than it wouldn't be repeatable from occasion to occasion. Therefore it's not JUST random noise!

History table values affect move ordering, and they change all the time. If you stop/re-start, you start off with different values than when you previously did the search. And as a result, you get different move ordering. LMR is sensitive to ordering and the shape of the tree can change dramatically due to this simple action. Hash table entries also affect move ordering (hash move is usually searched first) so you get yet another random change when you start over...

OK, lets consider the conditions when this might be useful. First, I don't use this technique unless one side has an advantage. Second, a move failing high isn't sufficient reason to use this technique. At a very minimum, a fail high must have occurred and a move change in the PV at a relatively high level, i.e. close to the root. How much of an advantage is needed for this to be useful is up for debate (25-50 centi-pawn?? of course higher is better here). I don't know how close the move change in the PV need to be to the root as I haven't tried to systematically test this. A rough guess is at least half the search depth and a third is probably better. e.g. on a 30 ply search if one or more fail-highs have occurred and a move change in the PV occurred at ply 10 (a third of the search depth) then its probably going to save time. The exact parameters would have to be determined by testing of course. This would be relatively easy to test in the SF testing framework I would think.

In any case, it does work and its not just random noise. I use it all the time to drive a good position to a winning position by finding better moves in less time!

Regards,

Forrest

Sorry, but there was NOTHING "dismissive" in my comment. And as far as "random noise" goes, anything can happen. The search for today's programs is HIGHLY non-deterministic. If you reduce the first 5 moves at a ply by nothing, the next 5 by 1 ply, the next 5 by 2 plies, etc, just shifting a move from position 20 to position 3 makes a 3 ply difference in how deeply it is searched. The history counters can cause this shift. And whenever you restart, or re-do, there is no way to get the history counters back to the same values. If you use more than one processor the problem is compounded. Seeing the right answer at different depths is hardly new or earth-shattering. It is the norm today.

Being "occasionally repeatable" does NOT mean this is not random behavior. Purely random behavior can repeat on occasion just as easily as not.