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
Did people try replacing LMR by pruning
Moderators: hgm, Rebel, chrisw
-
- Posts: 10281
- Joined: Thu Mar 09, 2006 12:37 am
- Location: Tel-Aviv Israel
-
- Posts: 4833
- Joined: Sun Aug 10, 2008 3:15 pm
- Location: Philippines
Re: Did people try replacing LMR by pruning
Can you simplify or explain further the above statement?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).
Re: Did people try replacing LMR by pruning
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..Ferdy wrote:Can you simplify or explain further the above statement?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).
Re: Did people try replacing LMR by pruning
oops yes at fail-high it also makes sense as depth changed. Well, i go to bed now.
adieguez wrote: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..Ferdy wrote:Can you simplify or explain further the above statement?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).
-
- Posts: 10281
- Joined: Thu Mar 09, 2006 12:37 am
- Location: Tel-Aviv Israel
Re: Did people try replacing LMR by pruning
I will give an exampleFerdy wrote:Can you simplify or explain further the above statement?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).
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
-
- Posts: 10281
- Joined: Thu Mar 09, 2006 12:37 am
- Location: Tel-Aviv Israel
Re: Did people try replacing LMR by pruning
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
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
-
- Posts: 2684
- Joined: Sat Jun 14, 2008 9:17 pm
Re: Did people try replacing LMR by pruning
Uri, when was last time you made some serious test of at least one of your ideas ?Uri Blass wrote: It is still not clear that the idea is bad ...
I wish you an happy and lucky new year Uri !
-
- Posts: 10281
- Joined: Thu Mar 09, 2006 12:37 am
- Location: Tel-Aviv Israel
Re: Did people try replacing LMR by pruning
I think 2 years ago or something like thatmcostalba wrote:Uri, when was last time you made some serious test of at least one of your ideas ?Uri Blass wrote: It is still not clear that the idea is bad ...
I wish you an happy and lucky new year Uri !
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
-
- Posts: 3196
- Joined: Fri May 26, 2006 3:00 am
- Location: WY, USA
- Full name: Michael Sherwin
Re: Did people try replacing LMR by pruning
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.Uri Blass wrote: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
If you are on a sidewalk and the covid goes beep beep
Just step aside or you might have a bit of heat
Covid covid runs through the town all day
Can the people ever change their ways
Sherwin the covid's after you
Sherwin if it catches you you're through
Just step aside or you might have a bit of heat
Covid covid runs through the town all day
Can the people ever change their ways
Sherwin the covid's after you
Sherwin if it catches you you're through
-
- Posts: 344
- Joined: Wed Sep 23, 2009 5:56 pm
- Location: Germany
Re: Did people try replacing LMR by pruning
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;