lmr in PV

[bob]

Yes, we do lmr in PV in Komodo. Yes, we know what works in Komodo, the question is what there is about Rybka, Robo and related programs that makes them reject LMR in PV while SF, Komodo and many others use it?

I thought about this a bit more. I now believe there are two reasons:

(1) someone copies an idea verbatim, and since the original did that, the copy does as well.

(2) someone uses some test positions (most likely tactical ones) and there it is quite common to find that reductions hurt, since in those positions, the idea of the position is that an unexpected (and often bad looking move like a sac) is the best move to play. LMR reduces the bad moves and makes it harder to notice that they are really good ones.

[bob]

Yes, we do lmr in PV in Komodo. Yes, we know what works in Komodo, the question is what there is about Rybka, Robo and related programs that makes them reject LMR in PV while SF, Komodo and many others use it?

I thought about this a bit more. I now believe there are two reasons:

(1) someone copies an idea verbatim, and since the original did that, the copy does as well.

(2) someone uses some test positions (most likely tactical ones) and there it is quite common to find that reductions hurt, since in those positions, the idea of the position is that an unexpected (and often bad looking move like a sac) is the best move to play. LMR reduces the bad moves and makes it harder to notice that they are really good ones.

[bob]

Thanks. I based my conclusion only on Rybka, Robo, Ippo, and Fire. I didn't realize that Ivanhoe was that different from Fire for example. Still, I wonder why the others all rejected LMR in PV when it is standard in all the unrelated top programs.

It is not about ELO. It is about long and pretty displayed pv lines. ELO may only be +3 for LMR in the pv.

Following that logic, you may remove TT cutoffs at pv nodes as well, which is another -3 ELO pts down at least to me.

Same for my testing. What's -3 elo here and there?

[lkaufman]

Since you don't distinguish node types for LMR, what are your conditions are how much do you reduce? I think the general conclusion of all the top rated programs outside the Rybka/robo family is that it does pay to reduce regardless of node type, but it pays to reduce less at PV nodes. I can't justify it theoretically, but we all find that this is what tests best.

[Houdini]

Yes, we do lmr in PV in Komodo. Yes, we know what works in Komodo, the question is what there is about Rybka, Robo and related programs that makes them reject LMR in PV while SF, Komodo and many others use it?

Houdini uses LMR in PV nodes except the root, it's worth about 10 to 15 Elo.

Robert

[Mincho Georgiev]

Thanks. I based my conclusion only on Rybka, Robo, Ippo, and Fire. I didn't realize that Ivanhoe was that different from Fire for example. Still, I wonder why the others all rejected LMR in PV when it is standard in all the unrelated top programs.

It is not about ELO. It is about long and pretty displayed pv lines. ELO may only be +3 for LMR in the pv.

Following that logic, you may remove TT cutoffs at pv nodes as well, which is another -3 ELO pts down at least to me.

Same for my testing. What's -3 elo here and there?

A Patzer ?

[bob]

Since you don't distinguish node types for LMR, what are your conditions are how much do you reduce? I think the general conclusion of all the top rated programs outside the Rybka/robo family is that it does pay to reduce regardless of node type, but it pays to reduce less at PV nodes. I can't justify it theoretically, but we all find that this is what tests best.

I am playing around with this right now, in fact. To date, I have found no change that works better than the current:

For all nodes, PV or non-PV, I never reduce the hash table move, any captures with see >= 0, nor any killer moves. I also do not reduce moves that give check, so long as the check has SEE >= 0. All other moves get reduced. The only variable I have for reduction is that the first move searched (which may well not be a hash, good capture or killer) is only reduced by 1 ply. All others are reduced by 2 plies. I have, as of yet, not found any gain in going to 3 or beyond, but am playing with it extensively.

I can go to 3 with no Elo gain or loss, but all it does is increase the search depth as reported, and with no Elo gain, I don't see any point in trying to exaggerate the search depth. I am experimenting with some different move ordering ideas that might pay off by allowing deeper reductions near the end of the list, to offset the additional computational cost of the ordering improvement...

Lots of testing to do, however...

[jdart]

I am doing something similar.

I do 1 ply reductions in the "history phase" of the search - this is after gainful or even captures and killers. Assuming the move is not extended for any reason (extensions and reductions are mutually exclusive).

Additional reduction can be done if the depth and move count are high enough. But for this to be done also more conditions must be met - move is not a capture or promotion (even a losing one), or a passed pawn move, and alpha is not a mate score, and we are not in the late endgame. (These same conditions are used for futility pruning - but that also is only done on non-PV nodes).

Clearly there are lots of things to vary here and what I have may not be optimal.