I played several sets of 8000 games (1000 initial positions, playing both colors, 4 opponents). I tried LMR counts from 3-18 in increments of 3's (3, 6, etc) at PV nodes, and from 2-10 by twos for non PV nodes. The moves after hash, then non-losing captures and finally killers were all sorted by using Evaluate() + Swap() which is pretty decent ordering. I found absolutely no difference for any of those counts. The idea was that I had to search N moves in "the rest of the search" (after the above moves) before applying LMR. I had a separate counter for PV and non-PV nodes.Daniel Shawul wrote:That was what I used to do before LMR become popular by Fruit/Glaurung.
I did constrained fail high reductions if eval() >= beta and looking at some other threats. It is same as LMR with the eval() <= alpha criteria. IMO LMR is more effective because it is recursive and has less constraints (The number of candidate nodes significantly reduces if we insert eval in to the equation)
I really want to see a comparison of LMR at PV nodes for different "L" threshold values at longer tc (say 40/10) for a good number of games. I am opposed to shorter tc because I believe the weirdest reduction/pruning gets away unpunished.
The "history pruning" idea of Toga is something I want to experiment with in the future. Again not because it makes a logical sense to me, but just because the trend nowadays to improve the branching factor as much as you can...
Personally I do not believe that an N value makes any sense anyway. In a simple endgame with N > 10 (say fine 70) you _never_ reduce. So I also tried a "percentage" that I varied from 10% to 90%, which said "don't reduce until N% of the remaining moves have been searched. I then repeated this and counted the first moves as well (good captures, killers, etc.)
And for each and every test I tried, it was either no better, or actually worse. It gets worse as you increase the value as LMR slowly gets turned off. A value of 0 was equivalent to the way I have been reducing with LMR...
I originally tried the history counter approach used in Fruit, with some tweaks for making the data a bit more usable. That also did not help. I have a couple of more ideas to try, but am not sure anything is going to help since it is nearly impossible to figure out which moves are going to be important farther down in the tree, until after they have been searched. And then it is too late...