LMR by another name

[sje]

LMR by another name

LMR (Late Move draft Reduction) is an idea that is fairly old, although in the Origins forum it is claimed by some to be more recent.

Back in the 1980s, I was using a form of LMR in my old program Spector. However, I did not call it such and did not write about it. Also, my form of LMR was different from the current table driven LMR. I called it RR (Ratio Reduction) and it worked by having some constant floating point value P (0 < P <= 1) and scaling the draft for the Nth move by P^N. At the time I was using fractional draft where one ply equaled 16 units of draft; this controlled the rounding error slightly.

RR did help the program somewhat and it deserved more experimentation time than what it got. A large part of its benefit was to keep the effects of the various extension heuristics under control.

[bob]

LMR by another name

LMR (Late Move draft Reduction) is an idea that is fairly old, although in the Origins forum it is claimed by some to be more recent.

Back in the 1980s, I was using a form of LMR in my old program Spector. However, I did not call it such and did not write about it. Also, my form of LMR was different from the current table driven LMR. I called it RR (Ratio Reduction) and it worked by having some constant floating point value P (0 < P <= 1) and scaling the draft for the Nth move by P^N. At the time I was using fractional draft where one ply equaled 16 units of draft; this controlled the rounding error slightly.

RR did help the program somewhat and it deserved more experimentation time than what it got. A large part of its benefit was to keep the effects of the various extension heuristics under control.

Bruce Moreland and I were discussing the concept back around the Jakarta chess tournament. I had accidentally broken something so that in the last couple of plies, I tried captures and quit. And things went quickly. Bruce experimented a bit with this. And as we talked, we liked the way it reduced the branching factor. But back then 10 ply searches were uncommon, and lopping so much off the last few plies was dangerous. We now call this futility pruning (or extended-futility pruning for last two plies, or really extended futility pruning for last 3 plies, etc).

In any case, when I say pruned, what I originally did was just that. And as we talked, I decided to just drop into q-search rather than giving up completely. But I never spent enough time on it, and we both noted "this needs further investigation, but probably not right before a WMCCC tournament. The thing we did NOT do was any exclusions (such as don't reduce checks, don't reduce killer moves, etc.) and and sort of variability depending on depth or moves searched or both. It was just "on or off". Which we now know is way too draconian.

It appears that Shredder was the first to really get this to working well, as suddenly he was searching 2-3-4 plies deeper than everyone. Then he eventually mentioned this to someone once others were doing so.

[bob]

LMR by another name

LMR (Late Move draft Reduction) is an idea that is fairly old, although in the Origins forum it is claimed by some to be more recent.

Back in the 1980s, I was using a form of LMR in my old program Spector. However, I did not call it such and did not write about it. Also, my form of LMR was different from the current table driven LMR. I called it RR (Ratio Reduction) and it worked by having some constant floating point value P (0 < P <= 1) and scaling the draft for the Nth move by P^N. At the time I was using fractional draft where one ply equaled 16 units of draft; this controlled the rounding error slightly.

RR did help the program somewhat and it deserved more experimentation time than what it got. A large part of its benefit was to keep the effects of the various extension heuristics under control.

Another thing by another name.

Back in the middle 70's, "blitz used null-move" But not as we use it today. Back then the search was selective, and one had to write code to deal with threats. I found it easier to write code to look for threats and move them up the list if found, but then did NOT want to have to write the inverse code to look for problems and try to solve them.

My solution, play a null-move, which changed sides. Now my threat detection would work pretty well and find the threats for the opponent. After I got that PV backed up to the point where I played the null move, I had a causality analyzer that would examine the PV and try to figure out what the problem was. For example, the PV might be Nxf7 Ke7 Nxh8 winning at least an exchange. Depending on how deep the search currently was, I would either assume I could address just that one threat, and looked to see if he had another, since dealing with two at once is a stretch. Or I would look at specific moves that prevented the problem outright. Moving the king or rook before they are forked, or defending f7 with a minor so that the knight can be captures if it takes on f7, breaking the fork.

Made us pretty strong, tactically, for that time period.