LMR questions

[bob]

Being a noob - this is just something I noticed.

In fact, today, I only extend checks with SEE >= 0. if SEE <= 0 I will actually REDUCE a check.

If you have a move with SEE = 0 you are effectively leaving a node alone (depth 5 + 1 - 1 = 5).

Why don't you just check whether SEE > 0 or < 0?

Just a thought.

BTW my LMR conditions are based on Tord's article on LMR.

Matthew:out

There's a typo in my comments. if check, and SEE >= 0, I extend and don't allow a reduction later. If check and SEE < 0, I do not extend and do reduce.

[bob]

If you have a move with SEE = 0 you are effectively leaving a node alone (depth 5 + 1 - 1 = 5).

Why don't you just check whether SEE > 0 or < 0?

I'm guessing Bob meant he only extends checks with SEE>=0 and reduces ones with SEE<0.

Correct. Not sure where that second = came from...

[Don]

I reduce moves based on the score they get after sorting the moves. In practice, that means I do not reduce hash moves, killers, winning captures, counter moves and queen promotions. I reduce everything else, but not if I'm in check.
If a reduced move fails high, it is re-searched without reductions.

I don't know whether that is "correct", but it seemed reasonable to me and it does seem to work.

What do you mean exactly by "counter moves"?

Think this was an old idea from the 80's maybe. Think of a counter move as a "killer move" but it is associated with a single move for the opponent. If the opponent plays move m1, at the next ply you try m1c first. More specific than killers. Never worked for me, although regular killers are a significant win.

I thought we called them refutation moves - that's what I called them. It was a table indexed by a move which stored the last known refutation of that move.

[lucasart]

OK so I played around with search reductions and extensions quite a bit (I don't like the LMR, because it give the wrong idea):

Code: Select all

// search extensions
int ext = msl.count == 1					// forced move
	|| (ms->m.check == 1 && ms->see >= 0)	// normal check, SEE >= 0
	|| ms->m.check == 2;					// discovered check, regardless of SEE
(...)
// move properties
const bool first = msl.idx == 1;
const bool capture = move_is_cop(ms->m);
const bool killer = move_equal(ms->m, si->killer[0]) || move_equal(ms->m, si->killer[1]);
const bool pthreat = move_is_7th_rank(ms->m) && ms->see >= 0;
const int hscore = capture ? 0 : get_history(B, ms->m);

// reduction decision
const bool bad_capture = capture && ms->see < 0;
const bool bad_quiet = !capture && &#40;hscore < 0 || &#40;hscore == 0 && ms->see < 0&#41;);
const bool reduce = UseLMR && !ext
	&& !first
	&& &#40;bad_capture || bad_quiet&#41;
	&& !killer
	&& !pthreat;

I have another two things to test:
(1) as suggested by Robert Hyatt, removing the single reply extension.
(2) not reducing normal checks with SEE < 0, contrary to what Robert suggests. But I'm stubborn and like to test before adopting

I suspect however that the single reply extension compensates for the lack of a king safety evaluation, and allow to find mates in the endgame quicker (for example mating a lone King with a Rook etc.)

[lucasart]

(2) not reducing normal checks with SEE < 0, contrary to what Robert suggests. But I'm stubborn and like to test before adopting

Scrap that, it's stupid (when there's only 1 legal move, this move is the first one and is not reduced... obviously)

[lucasart]

OK my test is finished, and once again Robert was right:
* bad checks (SEE < 0, non discovered checks) should -not only- not be extended, but in fact they should be reduced !
* next thing to test: remove the single reply extension

In the meantime, I launched a match between DoubleChekc and Jazz 5.01 (the UCI Linux x86_64 compile of Jim Ablett). I was a bit fed up of self testing at ultra fast time control (200 k nodes/move).

At the moment, and to my great surprise, DoubleCheck is proving to be a credible opponent to Jazz. DC is "only" losing by a 48% score after 100 games (tc 1min+1sec).

[Evert]

You may want to try the XBoard version as well.
I haven't actively done anything with the UCI version for more than a year and it may have some bugs I don't know about that don't affect the XBoard version.

[hgm]

The main reason to do check extension is to combat horizon effect, by having check+evasion push unavoidable losses over the horizon. That makes it logical that checks that lead to an immediate loss (because SEE < 0) do in general not need extension: they might push a loss over the horizon, but replace it by a new loss within the horizon, and thus will likely fail low anyway. With the possible exception of Pawn checks, where the Pawn sac might not enough to make you fail low.

In fact one might wonder if any check that already fails low at nominal depth deserves to be extended.

[lucasart]

You may want to try the XBoard version as well.
I haven't actively done anything with the UCI version for more than a year and it may have some bugs I don't know about that don't affect the XBoard version.

I'm using the file called "jazz-uci-501-64-ja" in
http://www.eglebbk.dds.nl/program/downl ... 501-ja.zip
it seems to work fine at blitz time control, and has a time stamp in October 2011.
are these two separate versions with code evolving differently ? I would have assumed, it was just a question of #ifdef's and different compiles

[Uri Blass]

The main reason to do check extension is to combat horizon effect, by having check+evasion push unavoidable losses over the horizon. That makes it logical that checks that lead to an immediate loss (because SEE < 0) do in general not need extension: they might push a loss over the horizon, but replace it by a new loss within the horizon, and thus will likely fail low anyway. With the possible exception of Pawn checks, where the Pawn sac might not enough to make you fail low.

In fact one might wonder if any check that already fails low at nominal depth deserves to be extended.

I can see another reason to do check extension.
After check the number of replies of the opponent is smaller so it is takes less time to search to bigger depth.