LMR revisited.

[MattieShoes]

Hmm. Perhaps a less drastic step would be to test with multiple variables simultaneously. All the pruning, reductions, and extensions interact in weird ways. So perhaps with this exact set of extensions and reductions, you've found the LMR conditions that work best.

But perhaps by turning on some extension that's bad by itself and making a change to LMR that is bad by itself, you just might end up better than before. There's an infinitude of tweaks one could try in conjunction, and I imagine most of those combinations would end up worse, but I bet a few combinations would prove beneficial and perhaps break you out of this deadlock

[Don]

Hmm. Perhaps a less drastic step would be to test with multiple variables simultaneously. All the pruning, reductions, and extensions interact in weird ways. So perhaps with this exact set of extensions and reductions, you've found the LMR conditions that work best.

But perhaps by turning on some extension that's bad by itself and making a change to LMR that is bad by itself, you just might end up better than before. There's an infinitude of tweaks one could try in conjunction, and I imagine most of those combinations would end up worse, but I bet a few combinations would prove beneficial and perhaps break you out of this deadlock

I do tend to test changes as if they are completely independent. However, it's pretty much a necessity as I have only a quad and duo core to test on, and testing combinations of features while getting even a few thousand games per player is very problematic for more than a few few combinations of features. So it seems like a necessary evil.

[bob]

Hmm. Perhaps a less drastic step would be to test with multiple variables simultaneously. All the pruning, reductions, and extensions interact in weird ways. So perhaps with this exact set of extensions and reductions, you've found the LMR conditions that work best.

But perhaps by turning on some extension that's bad by itself and making a change to LMR that is bad by itself, you just might end up better than before. There's an infinitude of tweaks one could try in conjunction, and I imagine most of those combinations would end up worse, but I bet a few combinations would prove beneficial and perhaps break you out of this deadlock

I do tend to test changes as if they are completely independent. However, it's pretty much a necessity as I have only a quad and duo core to test on, and testing combinations of features while getting even a few thousand games per player is very problematic for more than a few few combinations of features. So it seems like a necessary evil.

I'm with Don here. Otherwise you get an NxM testing requirement to test each of two values. If you don't do that you can just as easily miss interactions and never know they are there...

[Don]

Hmm. Perhaps a less drastic step would be to test with multiple variables simultaneously. All the pruning, reductions, and extensions interact in weird ways. So perhaps with this exact set of extensions and reductions, you've found the LMR conditions that work best.

But perhaps by turning on some extension that's bad by itself and making a change to LMR that is bad by itself, you just might end up better than before. There's an infinitude of tweaks one could try in conjunction, and I imagine most of those combinations would end up worse, but I bet a few combinations would prove beneficial and perhaps break you out of this deadlock

I do tend to test changes as if they are completely independent. However, it's pretty much a necessity as I have only a quad and duo core to test on, and testing combinations of features while getting even a few thousand games per player is very problematic for more than a few few combinations of features. So it seems like a necessary evil.

I'm with Don here. Otherwise you get an NxM testing requirement to test each of two values. If you don't do that you can just as easily miss interactions and never know they are there...

Once in a while, you know or strongly suspect that two things might be related, in which case you have to bite the bullet and test some combinations, but usually you cannot get them all and it's all pretty much based on superstition what you try.

[diep]

Another stupid idea came to me mind: what about to reduce moves does goes backward? i.e, for white side those with goes from file>4 to a file<=2 . Even maybe with a few more conditions to recognize a useless moves

I tried that a few years ago, didn't bring anything.

Vincent

[Kempelen]

More ideas: The tree searched is like a triangle. What about if we based reductions deph based on how far are we from the left side (that is, the pv). More far more reduction....

[bob]

More ideas: The tree searched is like a triangle. What about if we based reductions deph based on how far are we from the left side (that is, the pv). More far more reduction....

That is the L in LMR in fact, although I have tried this as well. So far, nothing significant has happened with the idea of reducing "later" moves more.

[Don]

More ideas: The tree searched is like a triangle. What about if we based reductions deph based on how far are we from the left side (that is, the pv). More far more reduction....

That is the L in LMR in fact, although I have tried this as well. So far, nothing significant has happened with the idea of reducing "later" moves more.

It works for me. As I said before, I reduce by 1 until I'm later in the list then I reduce by 2. So each move gets 0, 1 or 2 reductions.

[CRoberson]

More ideas: The tree searched is like a triangle. What about if we based reductions deph based on how far are we from the left side (that is, the pv). More far more reduction....

That is the L in LMR in fact, although I have tried this as well. So far, nothing significant has happened with the idea of reducing "later" moves more.

It works for me. As I said before, I reduce by 1 until I'm later in the list then I reduce by 2. So each move gets 0, 1 or 2 reductions.

Been trying this off and on for the last 3 years. Been calling it
Accelerated LMR in my notes. Generally, it doesn't combine well with
other ideas. I've finally found some constraints that make it only 20
Elo weaker than not using it. I suspect there is some merit with the
proper constraints thus I periodically go back to it.

Currently, it plays sort of wild. I don't use it due to how badly it
occasionally losses.

The issue with LMR is that it sees alternate good lines late. The value
of LMR is that it goes deeper on the PV quicker. So, you have two
choices: improve the weakness or the strength of LMR. I've been
working on both together and seperately. Its a hard nut to crack.
So, far I have mods that are slightly weaker than the baseline
algorithm.

[hgm]

OK, I have a suggestion:

The main disadvantage of LMR seems to be that it tends to make the engine blind against threats in side branches. This is particularly bad in combination with null moves: if the opponent can mount a dangerous attack with a sequence of late moves, while I am null-moving all the time, there is a reduction of 2 or 3 for each of my moves, and a reduction of 1 (or 2) for each of his moves, and you need excessive nominal depth before you start to see the trouble coming.

The deminishing returns of combining null-move pruning and LMR might not only be from that they partly do the same, but from that together they actually overdo it.

So my suggestion is: do not apply the LMR reduction to the null-move search of the daughter. E.g. if you use null move with R=2, when a node is reached through a late move, you would normally reduce the null move by R=3, and when it fails low, reduce the other moves by 1, and only if all these fail low too, you would search them unreduced (because the late move below you now fails high, and you take the reduction away.)

What I propose is to keep the reduction of the null move at R=2, but when it fails low, reduce all the normal moves still by 1.

This should make you much less blind. And my suspicion is that it would be comparatively cheap, because I already did try the opposite: only reduce the null move one extra after a late move, and switch to normal depth immediately when it fails low. This hardly produced any reduction of the tree size for the same nominal depth. Apparently the branches with null moves are already so much reduced, that they hrdly contribute to the node count of the tree, and reducing them further has no measurable effect on tree size, but a very detrimental effect on playing strength! So you might as well extend them, in the hope that the opposite will hold.