Did people try replacing LMR by pruning

[Uri Blass]

The idea is the following:

Every time that LMR conditions happen you do not change the depth but increase pruning variable by 1 when the pruning variable is simply the number of times when LMR conditions happened during the path(of course you need to reduce it when you take back the last move).

If the pruning variable is bigger or equal to the remaining depth
then you decide if to prune or not to prune based on evaluation or based on result of the qsearch.

Uri

[Ferdy]

Every time that LMR conditions happen you do not change the depth but increase pruning variable by 1 when the pruning variable is simply the number of times when LMR conditions happened during the path(of course you need to reduce it when you take back the last move).

Can you simplify or explain further the above statement?

[adieguez]

Every time that LMR conditions happen you do not change the depth but increase pruning variable by 1 when the pruning variable is simply the number of times when LMR conditions happened during the path(of course you need to reduce it when you take back the last move).

Can you simplify or explain further the above statement?

it probably means exactly what he said, altough speaking about the qsearch is strange since the prunning should be in a fail-low node, after seeing first captures and every other move which is not normally reduced. I could try it, altough it is a bit complicated for me to do the change, first I would have to remove some code to simplify a bit the reductions, test that version, and then do Uri change and test then the change. Spending two nights of testing for this.. mmh.. I don't know..

[adieguez]

oops yes at fail-high it also makes sense as depth changed. Well, i go to bed now.

Every time that LMR conditions happen you do not change the depth but increase pruning variable by 1 when the pruning variable is simply the number of times when LMR conditions happened during the path(of course you need to reduce it when you take back the last move).

Can you simplify or explain further the above statement?

it probably means exactly what he said, altough speaking about the qsearch is strange since the prunning should be in a fail-low node, after seeing first captures and every other move which is not normally reduced. I could try it, altough it is a bit complicated for me to do the change, first I would have to remove some code to simplify a bit the reductions, test that version, and then do Uri change and test then the change. Spending two nights of testing for this.. mmh.. I don't know..

[Uri Blass]

Every time that LMR conditions happen you do not change the depth but increase pruning variable by 1 when the pruning variable is simply the number of times when LMR conditions happened during the path(of course you need to reduce it when you take back the last move).

Can you simplify or explain further the above statement?

I will give an example

Normal LMR at depth 7
opening position
1.e4(remaining depth 6)
1... Nf6(reduced by LMR remaining depth 4)
2.e5(remaining depth 3)
2...Nh5(reduced by LMR remaining depth 1)
3.Qxh5(remaining depth 0) go to qsearch bad for black

pruning instead of LMR
1.e4(remaining depth 6,pruning number 0)
1...Nf6(remaining depth 5,pruning number 1 pruning side black)
2.e5(remaining depth 4,pruning number 1)
2...Nh5(remaining depth 3,pruning number 2 pruning side black)
3.Qxh5(remaining depth 2,pruning number 2)
pruning number is equal to remaining depth so you need to decide if to prune.

The reduced moves are moves of black so you can expect it to be bad for black.

You can verify it or by static evaluation or by qsearch and decide to prune simply if the position is bad for black that means fail low.

In case of fail high you do not need to do research with bigger depth like people do in normal LMR and you simply do not prune and continue to search.

Uri

[Uri Blass]

Thinking about it there is one disadvantage relative to normal LMR and that you may do additional searches.

The reason is that it may be possible that you get unexpected fail high in one branch of the tree below the reduction but not fail high for all the tree,

In this case the pruning instead of LMR is going to search the wrong branch deeper when the LMR is going to not going to fail high so it is not going to search the wrong branch deeper.

It is still not clear that the idea is bad because the advantage of not doing researches may be higher and it is possible to use the same idea together with LMR in order to give more reductions to some moves.

Uri

[mcostalba]

It is still not clear that the idea is bad ...

Uri, when was last time you made some serious test of at least one of your ideas ?


I wish you an happy and lucky new year Uri !

[Uri Blass]

It is still not clear that the idea is bad ...

Uri, when was last time you made some serious test of at least one of your ideas ?


I wish you an happy and lucky new year Uri !

I think 2 years ago or something like that

today I prefer to use computer time for my correspondence games
so I cannot do serious tests.

I wish you also happy new year.

Uri

[Michael Sherwin]

The idea is the following:

Every time that LMR conditions happen you do not change the depth but increase pruning variable by 1 when the pruning variable is simply the number of times when LMR conditions happened during the path(of course you need to reduce it when you take back the last move).

If the pruning variable is bigger or equal to the remaining depth
then you decide if to prune or not to prune based on evaluation or based on result of the qsearch.

Uri

A few years back I tried LMP in RomiChess iirc P3a. That version is the only version that ever won a WBEC test tournament. And it did it with a perfect score of 18-0! When I changed the LMR to 2 I gave up on LMP as a LMR of 2 was just as efficient with out as much risk. You BTW, participated in that discussion. LMP was also used in Glaurung 2.x! I have not looked to see if it is retained in Stockfish.

[metax]

Stockfish 1.6:

Code: Select all

// Move count based pruning
          if (   moveCount >= FutilityMoveCountMargin
              && ok_to_prune(pos, move, ss[ply].threatMove)
              && bestValue > value_mated_in(PLY_MAX))
              continue;