bob wrote:I don't have any history counters in Crafty. I found that at the depths I see today, the history counters were simply saturated with nonsense...
My experience is different. I still haven't found anything better than history counters for ordering the remaining non-captures after the killer moves. I have tried many approaches (ordering by piece square tables, static exchange evaluation, moving hanging pieces to safe squares, defending the destination square of the null move refutation at the current node, etc.), but to my surprise, history counters perform better than everything else (or at least they did the last time I tried). There also doesn't seem to be a trend that the efficiency of history move ordering decreases at big depths with my program, as long as I scale down the history scores sufficiently often.
I agree about using history counters for LMR, though. They seem to have zero effect in my program, and I currently don't use them (although I did use them in the public Glaurung 2.0.1).
Tord
I think I reported this previously, but in working on history counters for LMR, I tried to find the right "value" for Crafty, on a parameter that varied from 0% to 100%, where 100% said "if this move failed high every time it was tried don't reduce it", 50% said "if this move failed high 50% of the time or more, don't reduce it, and 0% said "always reduce". I played 5,000 game silver-type matches against each of 4 opponents, varying the reduce value from 20-80. The results were random. I then included 0, 10 and 90 and 100 and the results were still random. That is, there was no point in the curve where the X axis was the threshold value (0 to 100) and the Y axis was the game result, where you could identify "this is the optimal". You would expect the results to improve until you hit the perfect spot, then start to fall off on the other side. No such luck. The results were just random samples. I then repeated this using fruit 2.1 and found exactly the same thing, the history pruning value had no significance in how the program performed over that large set of games...
bob wrote:I don't have any history counters in Crafty. I found that at the depths I see today, the history counters were simply saturated with nonsense...
My experience is different. I still haven't found anything better than history counters for ordering the remaining non-captures after the killer moves. I have tried many approaches (ordering by piece square tables, static exchange evaluation, moving hanging pieces to safe squares, defending the destination square of the null move refutation at the current node, etc.), but to my surprise, history counters perform better than everything else (or at least they did the last time I tried). There also doesn't seem to be a trend that the efficiency of history move ordering decreases at big depths with my program, as long as I scale down the history scores sufficiently often.
I agree about using history counters for LMR, though. They seem to have zero effect in my program, and I currently don't use them (although I did use them in the public Glaurung 2.0.1).
Tord
I think I reported this previously, but in working on history counters for LMR, I tried to find the right "value" for Crafty, on a parameter that varied from 0% to 100%, where 100% said "if this move failed high every time it was tried don't reduce it", 50% said "if this move failed high 50% of the time or more, don't reduce it, and 0% said "always reduce". I played 5,000 game silver-type matches against each of 4 opponents, varying the reduce value from 20-80. The results were random. I then included 0, 10 and 90 and 100 and the results were still random. That is, there was no point in the curve where the X axis was the threshold value (0 to 100) and the Y axis was the game result, where you could identify "this is the optimal". You would expect the results to improve until you hit the perfect spot, then start to fall off on the other side. No such luck. The results were just random samples. I then repeated this using fruit 2.1 and found exactly the same thing, the history pruning value had no significance in how the program performed over that large set of games...
I removed it and have not looked back...
The question is if you found that history counters are not productive for order of moves in your tests.
Tord claims that they are productive for better order of moves but not productive as a condition for LMR.
bob wrote:I don't have any history counters in Crafty. I found that at the depths I see today, the history counters were simply saturated with nonsense...
My experience is different. I still haven't found anything better than history counters for ordering the remaining non-captures after the killer moves. I have tried many approaches (ordering by piece square tables, static exchange evaluation, moving hanging pieces to safe squares, defending the destination square of the null move refutation at the current node, etc.), but to my surprise, history counters perform better than everything else (or at least they did the last time I tried). There also doesn't seem to be a trend that the efficiency of history move ordering decreases at big depths with my program, as long as I scale down the history scores sufficiently often.
I agree about using history counters for LMR, though. They seem to have zero effect in my program, and I currently don't use them (although I did use them in the public Glaurung 2.0.1).
Tord
I think I reported this previously, but in working on history counters for LMR, I tried to find the right "value" for Crafty, on a parameter that varied from 0% to 100%, where 100% said "if this move failed high every time it was tried don't reduce it", 50% said "if this move failed high 50% of the time or more, don't reduce it, and 0% said "always reduce". I played 5,000 game silver-type matches against each of 4 opponents, varying the reduce value from 20-80. The results were random. I then included 0, 10 and 90 and 100 and the results were still random. That is, there was no point in the curve where the X axis was the threshold value (0 to 100) and the Y axis was the game result, where you could identify "this is the optimal". You would expect the results to improve until you hit the perfect spot, then start to fall off on the other side. No such luck. The results were just random samples. I then repeated this using fruit 2.1 and found exactly the same thing, the history pruning value had no significance in how the program performed over that large set of games...
I removed it and have not looked back...
The question is if you found that history counters are not productive for order of moves in your tests.
Tord claims that they are productive for better order of moves but not productive as a condition for LMR.
Uri
I tested both ideas. For move ordering, I don't play games usually, as it is easier and better to pick a bunch of positions and test the two move ordering approaches and compare times.
So I basically tested the effect of various LMR/history-threshold values for both fruit and crafty and found that they are all essentially equal, and simpler is better so I just removed the stuff. For move ordering, history moves might help a little bit, but then the counter updates cost something. For me removing them produced faster searches in the positions I tested overall...