TalkChess.com

Sorry to bother you all. In relation to the following link.....

http://chessprogramming.wikispaces.com/ ... s/12040041

Is this making sense?

Remember that 2 == 1 ply
Christopher

This is the LMR reduction depth of that engine Ippolit.

I had already noted that is incredibly aggressive. Normally LMR reduction is fixed and is applied after the first n moves, where n can vary from 2-3 in non pv node to something more (10 in SF) in PV nodes.

Some time ago I have tried in SF at increasing to reduction of 2 plies after 15-20 moves but with disastrousus results.

Now, well yesteday, I have seen that in Ippolit an even more aggressive rule is used. Reduction is based on move count according to a logaritmic scale.

I had written some notes yesterday that I report here below:

Here bit_scan_reverse(4 + moveCount) is clearly a shortcut to calculate log in base two of moveCount + 4.

I (still) didn't tried that but I have great doubts that it can work, at least with SF, because when I tried a much more cautious "double reduction after 20 moves" it failed.

mcostalba wrote:This is the LMR reduction depth of that engine Ippolit.

I had already noted that is incredibly aggressive. Normally LMR reduction is fixed and is applied after the first n moves, where n can vary from 2-3 in non pv node to something more (10 in SF) in PV nodes.

Some time ago I have tried in SF at increasing to reduction of 2 plies after 15-20 moves but with disastrousus results.

Now, well yesteday, I have seen that in Ippolit an even more aggressive rule is used. Reduction is based on move count according to a logaritmic scale.

I had written some notes yesterday that I report here below:

Code: Select all

- Variable depth LMR based on move number:
 Depth newDepth = depth - OnePly - (4 + bit_scan_reverse(4 + moveCount));

where bit_scan_reverse(4 + moveCount) equals to

 2 if moveCount in range [0, 8)
 3 if moveCount in range [8, 16)
 4 if moveCount in range [16, 32)
 5 if moveCount in range [32, 64)

Here bit_scan_reverse(4 + moveCount) is clearly a shortcut to calculate log in base two of moveCount + 4.

I (still) didn't tried that but I have great doubts that it can work, at least with SF, because when I tried a much more cautious "double reduction after 20 moves" it failed.

That is very interesting Marco. It is quite dangerous stuff to do.

BTW....the above stuff in my original post (the code part) is actually Rybka, so we can conclude something it seems.



It may even provide a topic of discussion in here.

Thanks

Christopher

PS Even I am getting used to the name Stockfish now.

Christopher Conkie wrote:Sorry to bother you all. In relation to the following link.....

http://chessprogramming.wikispaces.com/ ... s/12040041

Is this making sense?

Remember that 2 == 1 ply

Code: Select all

Cut node reduction: 6, 6, 6, 6, 7, 7, 7, 7, 7, 7, 7, 7, 8, 8, 8, 8, 8, 8, 8, 8,
8, 8, 8, 8, 8, 8, 8, 8, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9,
 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10,
10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10,
10, 10, 10, 10, 10, 10, 10, 10, 10, 10

All node reduction: 1, 1, 2, 2, 3, 3, 3, 3, 4, 4, 4, 4, 4, 4, 4, 4, 5, 5, 5, 5,
5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6,
 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7
, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7,
7

Christopher

if 2=> one ply, the above is not quite as speculative-looking. Is this indexed by remaining depth? Moves searched at a ply? However, 7 (3.5) is not that big a value. I've experimented with an increasing reduction as more and more moves fail to produce a cutoff, but have yet to find anything that improves the basic algorithm I have been using for several years now. At least so far.

bob wrote:

Christopher Conkie wrote:Sorry to bother you all. In relation to the following link.....

http://chessprogramming.wikispaces.com/ ... s/12040041

Is this making sense?

Remember that 2 == 1 ply

Code: Select all

Cut node reduction: 6, 6, 6, 6, 7, 7, 7, 7, 7, 7, 7, 7, 8, 8, 8, 8, 8, 8, 8, 8,
8, 8, 8, 8, 8, 8, 8, 8, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9,
 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10,
10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10,
10, 10, 10, 10, 10, 10, 10, 10, 10, 10

All node reduction: 1, 1, 2, 2, 3, 3, 3, 3, 4, 4, 4, 4, 4, 4, 4, 4, 5, 5, 5, 5,
5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6,
 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7
, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7,
7

Christopher

if 2=> one ply, the above is not quite as speculative-looking. Is this indexed by remaining depth? Moves searched at a ply? However, 7 (3.5) is not that big a value. I've experimented with an increasing reduction as more and more moves fail to produce a cutoff, but have yet to find anything that improves the basic algorithm I have been using for several years now. At least so far.

I think that big reductions can work only with good order of moves
so if you want to have big reductions you need to improve the order of moves.

Uri

bob wrote: if 2=> one ply, the above is not quite as speculative-looking. Is this indexed by remaining depth? Moves searched at a ply? However, 7 (3.5) is not that big a value. I've experimented with an increasing reduction as more and more moves fail to produce a cutoff, but have yet to find anything that improves the basic algorithm I have been using for several years now. At least so far.

- Indexed by Moves searched at a ply

- 3.5 ply reduction is not a big value ????????

LMR has a recursive behaviour for the moves near the list end, even if reduction is only one ply and we are let's say at depth 12, when we reach depth 5 the late moves of the lates moves of the lates moves ... will be reduced by 7 ply already because at each next ply you add one ply of reduction to late moves.

So reducing 3.5 for a _single_ ply is a _tremendous_ reduction IMHO.

mcostalba wrote:This is the LMR reduction depth of that engine Ippolit.

I had already noted that is incredibly aggressive. Normally LMR reduction is fixed and is applied after the first n moves, where n can vary from 2-3 in non pv node to something more (10 in SF) in PV nodes.

Some time ago I have tried in SF at increasing to reduction of 2 plies after 15-20 moves but with disastrousus results.

Now, well yesteday, I have seen that in Ippolit an even more aggressive rule is used. Reduction is based on move count according to a logaritmic scale.

I had written some notes yesterday that I report here below:

Code: Select all

- Variable depth LMR based on move number:
 Depth newDepth = depth - OnePly - (4 + bit_scan_reverse(4 + moveCount));

where bit_scan_reverse(4 + moveCount) equals to

 2 if moveCount in range [0, 8)
 3 if moveCount in range [8, 16)
 4 if moveCount in range [16, 32)
 5 if moveCount in range [32, 64)

Here bit_scan_reverse(4 + moveCount) is clearly a shortcut to calculate log in base two of moveCount + 4.

I (still) didn't tried that but I have great doubts that it can work, at least with SF, because when I tried a much more cautious "double reduction after 20 moves" it failed.

My hypothesis why this could not be working in Stockfish is that we already have the "super-quiescence"-approach (often called history pruning). Basically we are throwing moves out of the window already at depth == 6. Combined with aggressive LMR it just prunes so much. So if we want to try the aggressive LMR thing, we need to in one way or another disable/mild the history pruning.

mcostalba wrote:

bob wrote: if 2=> one ply, the above is not quite as speculative-looking. Is this indexed by remaining depth? Moves searched at a ply? However, 7 (3.5) is not that big a value. I've experimented with an increasing reduction as more and more moves fail to produce a cutoff, but have yet to find anything that improves the basic algorithm I have been using for several years now. At least so far.

- Indexed by Moves searched at a ply

- 3.5 ply reduction is not a big value ????????

Notice the wording: "not quite as speculative". I have tried 2 and 3, just as I have tried null-move reductions of 1, 2, 3, 4, 5. I am using 3 at the moment for NM. And 1 for LMR. So while it is pretty aggressive, it is not nearly as wild as the original 7 value I saw and thought wow... 7 plies???

LMR has a recursive behaviour for the moves near the list end, even if reduction is only one ply and we are let's say at depth 12, when we reach depth 5 the late moves of the lates moves of the lates moves ... will be reduced by 7 ply already because at each next ply you add one ply of reduction to late moves.

So reducing 3.5 for a _single_ ply is a _tremendous_ reduction IMHO.

Don't disagree. But it is not "as tremendous" as 7 plies.

Uri Blass wrote:

bob wrote:

Christopher Conkie wrote:Sorry to bother you all. In relation to the following link.....

http://chessprogramming.wikispaces.com/ ... s/12040041

Is this making sense?

Remember that 2 == 1 ply

Code: Select all

Cut node reduction: 6, 6, 6, 6, 7, 7, 7, 7, 7, 7, 7, 7, 8, 8, 8, 8, 8, 8, 8, 8,
8, 8, 8, 8, 8, 8, 8, 8, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9,
 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10,
10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10,
10, 10, 10, 10, 10, 10, 10, 10, 10, 10

All node reduction: 1, 1, 2, 2, 3, 3, 3, 3, 4, 4, 4, 4, 4, 4, 4, 4, 5, 5, 5, 5,
5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 5, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6,
 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 6, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7
, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7, 7,
7

Christopher

if 2=> one ply, the above is not quite as speculative-looking. Is this indexed by remaining depth? Moves searched at a ply? However, 7 (3.5) is not that big a value. I've experimented with an increasing reduction as more and more moves fail to produce a cutoff, but have yet to find anything that improves the basic algorithm I have been using for several years now. At least so far.

I think that big reductions can work only with good order of moves
so if you want to have big reductions you need to improve the order of moves.

Uri

And what would that be? History stuff sucks. Already tested that to death along with this very idea and could not get it to work any better than current move ordering. I don't generate moves in random order, but that is about all I would claim, there is a _little_ rhyme to the reason of how my move generator produces moves, but it is hardly "qualitatively ordered based on the goodness of each move."

zamar wrote: My hypothesis why this could not be working in Stockfish is that we already have the "super-quiescence"-approach (often called history pruning). Basically we are throwing moves out of the window already at depth == 6.

They throw out even more !

I am still working on the details, but it seems that below a certain depth they try only sliding pieces moves and forget about the pawns !