Hardware vs Software

[bob]

By the way, it's amusing to see that LMR is now generally accepted as effective. Back when I started advocating it, the technique was largely abandoned since many years, and those few programmers I managed to convince to give it a try mostly reported that it didn't work for them.

Amusing indeed. The Problem with LMR is finding the right parameters. And that takes time. I was lucky to find the right values in my first try never to find better ones in the xx improvement-tries thereafter. The world up-side-down so to say

Ed

I think the problem was caused by the original "source".

When Bruce Moreland and I first played with this idea, we didn't get anywhere with it. But we didn't spend a lot of time trying to figure out what to not reduce. And we gave up quickly thinking that it was too dangerous, which it probably was back then.

Then along came fruit and "history pruning" and everyone jumped on the bandwagon again, but using a badly broken approach based on history counters. I found that the history counter stuff was simply "noise" and no tuning of the history threshold made any difference in how Crafty played, nor after testing on our cluster to verify that Crafty wasn't broken, that it made no difference in how fruit played either. But rather than giving up, I continued to experiment and arrived at what I do today, which does work. It is not a +100 or +200 Elo win, if you saw my cluster results I posted a few months back (LMR is worth about +60, if you already have null move. Null-move is worth about +60 if you already have LMR. If you use neither, you are missing out on about +120 elo total, which is significant. But since null-move and LMR have an "overlap" (both do reduced-depth searches) you get less from one if you already have the other...

And there is likely more left to do in selecting which branches to not reduce, such as the "sticky trans/ref table" idea used in deep-thought / deep-blue to make sure that once you extend a position, you continue to extend it for at least another iteration or two. Same idea could apply to reductions...

It's hard to define fixed elo jumps for new idea's as it varies from program to program based what's already in a program. LMR gave mine only +30 because of the various "static reductions" I do. The same applied for null-move only +20-30 because of my own selective search stuff.

Ed

Your numbers might be closer to mine as I did not pay a lot of attention when I ran the test, someone asked and I tested to see. The thing I remember was that removing both was significant, might have been -60 to -90 total. Removing one was far less than I had expected, say -30. Adding either one by itself was maybe +60. But once I had one on (either one) adding the other was a modest improvement... I'll try to find the actual post that was done here about 3 months ago...

[hgm]

It was on the first page of this very thread: +80 Elo for one, +120 for both added.

http://www.talkchess.com/forum/viewtopi ... 15&start=8

[bob]

It was on the first page of this very thread: +80 Elo for one, +120 for both added.

http://www.talkchess.com/forum/viewtopi ... 15&start=8

Thanks. For some reason, the numbers did not "jump out" and I did not remember and did not want to run it again.

That matches my memory conceptually, that one offered significant improvement, while the other was about 1/2, no matter which was first or second...