Negative Plausibility Move Ordering
Posted: Thu Jul 09, 2009 9:05 pm
Has anyone tested the move ordering method described on http://www.aifactory.co.uk/newsletter/2 ... bility.htm?
Looks like an Alternative of Relative History Heuristic, as proposed by Bob in late move reductions, March 01, 2006.Alessandro Damiani wrote:Has anyone tested the move ordering method described on http://www.aifactory.co.uk/newsletter/2 ... bility.htm?
I was going to say it looks like yahm, (yet another history methodology). So far, I have found absolutely no history approach that helps. I have turned it off in several programs on my cluster and it made absolutely no difference in the Elo at all. Probably is workable for very shallow search depths. But we aren't seeing very shallow search depths today.Gerd Isenberg wrote:Looks like an Alternative of Relative History Heuristic, as proposed by Bob in late move reductions, March 01, 2006.Alessandro Damiani wrote:Has anyone tested the move ordering method described on http://www.aifactory.co.uk/newsletter/2 ... bility.htm?
It's truly bizarre that this is true in your program. In my program it definitely helps to use the history heuristic for move ordering. I don't use the classic version of HH but the version that considers how often it's chosen when the move is possible.bob wrote:I was going to say it looks like yahm, (yet another history methodology). So far, I have found absolutely no history approach that helps. I have turned it off in several programs on my cluster and it made absolutely no difference in the Elo at all. Probably is workable for very shallow search depths. But we aren't seeing very shallow search depths today.Gerd Isenberg wrote:Looks like an Alternative of Relative History Heuristic, as proposed by Bob in late move reductions, March 01, 2006.Alessandro Damiani wrote:Has anyone tested the move ordering method described on http://www.aifactory.co.uk/newsletter/2 ... bility.htm?
What do you do about the "other" moves in the list? When I say "other" or "rest" I mean the moves that are not normally put at the top of the list, such as killers, captures, hash table moves and promotions.bob wrote:I was going to say it looks like yahm, (yet another history methodology). So far, I have found absolutely no history approach that helps. I have turned it off in several programs on my cluster and it made absolutely no difference in the Elo at all. Probably is workable for very shallow search depths. But we aren't seeing very shallow search depths today.Gerd Isenberg wrote:Looks like an Alternative of Relative History Heuristic, as proposed by Bob in late move reductions, March 01, 2006.Alessandro Damiani wrote:Has anyone tested the move ordering method described on http://www.aifactory.co.uk/newsletter/2 ... bility.htm?
You didn't read my post carefully enough. I didn't just test it in my program. I disabled it in the other programs that use it that I run on my cluster. It made zero difference... Note I am not talking about ordering either. I am talking about pruning/reduction decisions only...Don wrote:It's truly bizarre that this is true in your program. In my program it definitely helps to use the history heuristic for move ordering. I don't use the classic version of HH but the version that considers how often it's chosen when the move is possible.bob wrote:I was going to say it looks like yahm, (yet another history methodology). So far, I have found absolutely no history approach that helps. I have turned it off in several programs on my cluster and it made absolutely no difference in the Elo at all. Probably is workable for very shallow search depths. But we aren't seeing very shallow search depths today.Gerd Isenberg wrote:Looks like an Alternative of Relative History Heuristic, as proposed by Bob in late move reductions, March 01, 2006.Alessandro Damiani wrote:Has anyone tested the move ordering method described on http://www.aifactory.co.uk/newsletter/2 ... bility.htm?
I have found that it's difficult to improve on that for the "other" moves - the ones beyond captures, killers, etc.
It's crazy but different people report different things. For Rebel, Ed sorts by a piece square table and reports that it definitely helps. It doesn't for me!
- Don
Where in your post did you say that? You didn't.bob wrote:You didn't read my post carefully enough. I didn't just test it in my program. I disabled it in the other programs that use it that I run on my cluster. It made zero difference... Note I am not talking about ordering either. I am talking about pruning/reduction decisions only...Don wrote:It's truly bizarre that this is true in your program. In my program it definitely helps to use the history heuristic for move ordering. I don't use the classic version of HH but the version that considers how often it's chosen when the move is possible.bob wrote:I was going to say it looks like yahm, (yet another history methodology). So far, I have found absolutely no history approach that helps. I have turned it off in several programs on my cluster and it made absolutely no difference in the Elo at all. Probably is workable for very shallow search depths. But we aren't seeing very shallow search depths today.Gerd Isenberg wrote:Looks like an Alternative of Relative History Heuristic, as proposed by Bob in late move reductions, March 01, 2006.Alessandro Damiani wrote:Has anyone tested the move ordering method described on http://www.aifactory.co.uk/newsletter/2 ... bility.htm?
I have found that it's difficult to improve on that for the "other" moves - the ones beyond captures, killers, etc.
It's crazy but different people report different things. For Rebel, Ed sorts by a piece square table and reports that it definitely helps. It doesn't for me!
- Don
HH helped for me too. But my depths are less than crafty or the other very strong engines.Don wrote:It's truly bizarre that this is true in your program. In my program it definitely helps to use the history heuristic for move ordering. I don't use the classic version of HH but the version that considers how often it's chosen when the move is possible.bob wrote:I was going to say it looks like yahm, (yet another history methodology). So far, I have found absolutely no history approach that helps. I have turned it off in several programs on my cluster and it made absolutely no difference in the Elo at all. Probably is workable for very shallow search depths. But we aren't seeing very shallow search depths today.Gerd Isenberg wrote:Looks like an Alternative of Relative History Heuristic, as proposed by Bob in late move reductions, March 01, 2006.Alessandro Damiani wrote:Has anyone tested the move ordering method described on http://www.aifactory.co.uk/newsletter/2 ... bility.htm?
I have found that it's difficult to improve on that for the "other" moves - the ones beyond captures, killers, etc.
It's crazy but different people report different things. For Rebel, Ed sorts by a piece square table and reports that it definitely helps. It doesn't for me!
- Don
I quoted Bob's "late move reductions" post, where he proposed to "penalize" early moves while a later move failed high is similar to Jeff's Negative Plausibility. However, Bob was focused on LMR there, but later abandoned (relative) HH for LMR as well for move ordering.Don wrote:Where in your post did you say that? You didn't.bob wrote: You didn't read my post carefully enough. I didn't just test it in my program. I disabled it in the other programs that use it that I run on my cluster. It made zero difference... Note I am not talking about ordering either. I am talking about pruning/reduction decisions only...
There is nothing in your post that would lead any reader to conclude that you meant something different, especially when the whole thread is about move ordering.
I think that any reasonable interpretation is that you don't use the history heuristic (because you said it doesn't work for you.) There is nothing in your post that would lead any reader to conclude that you meant something different that what you actually said. Just because YOU know what you meant doesn't mean you wrote it down clearly and so you accuse the reader of being sloppy when it was really the writer who was sloppy.
It's crazy but different people report different things. For Rebel, Ed sorts by a piece square table and reports that it definitely helps. It doesn't for me!
I have found that it's difficult to improve on that for the "other" moves - the ones beyond captures, killers, etc.
- Don
You are correct. Perhaps I had it confused with a different thread on the same topic, am not sure. But in any case, to make the point, history can be applied in three areas. ordering, reduction and pruning. I am explicitly talking about reduction and pruning. I removed history ordering a long while back after testing showed zero benefit (or loss) to using it. I have tried lots of ways to use history information of various sorts to limit reductions and pruning. And have found nothing that works. I have even turned off the history part of reductions and pruning for various programs and found that it made no difference in them either...Don wrote:Where in your post did you say that? You didn't.bob wrote:You didn't read my post carefully enough. I didn't just test it in my program. I disabled it in the other programs that use it that I run on my cluster. It made zero difference... Note I am not talking about ordering either. I am talking about pruning/reduction decisions only...Don wrote:It's truly bizarre that this is true in your program. In my program it definitely helps to use the history heuristic for move ordering. I don't use the classic version of HH but the version that considers how often it's chosen when the move is possible.bob wrote:I was going to say it looks like yahm, (yet another history methodology). So far, I have found absolutely no history approach that helps. I have turned it off in several programs on my cluster and it made absolutely no difference in the Elo at all. Probably is workable for very shallow search depths. But we aren't seeing very shallow search depths today.Gerd Isenberg wrote:Looks like an Alternative of Relative History Heuristic, as proposed by Bob in late move reductions, March 01, 2006.Alessandro Damiani wrote:Has anyone tested the move ordering method described on http://www.aifactory.co.uk/newsletter/2 ... bility.htm?
There is nothing in your post that would lead any reader to conclude that you meant something different, especially when the whole thread is about move ordering.
[/quote]
I have found that it's difficult to improve on that for the "other" moves - the ones beyond captures, killers, etc.
It's crazy but different people report different things. For Rebel, Ed sorts by a piece square table and reports that it definitely helps. It doesn't for me!
- Don