Negative Plausibility Move Ordering

[Don]

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...

Where in your post did you say that? You didn't.

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.

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.
http://www.talkchess.com/forum/viewtopi ... 24&t=18345

You might have quoted it, but Bob didn't quote it and this was about my carefully reading HIS posts, not your posts.

[Don]

... 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...

I have just completed a bunch of experiments with MOVE ORDERING. I'm tried using the piece square tables, full evaluation and history heuristic. I think this is what you call the "relative history heuristic" which seems to be a definite improvement. I also tried random move ordering.

In general ANY move ordering helps over doing nothing at all, even random move ordering. As it turns out, a good bit of the benefit is had when I put losing (non capture) move at the end of the list. But it's clear that for my program, move ordering beyond the captures and killers is a good thing and not by just a trivial amount. It's better in two ways, it searches faster and it plays better at the same depth. The only reason that it would play better is that LMR is sensitive to move ordering - even though I do not use any of this for pruning decision.

So my question is do you do ANYTHING about move ordering beyond the captures and killers etc, or just try moves in the order they are generated?

[MattieShoes]

... 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...

I have just completed a bunch of experiments with MOVE ORDERING. I'm tried using the piece square tables, full evaluation and history heuristic. I think this is what you call the "relative history heuristic" which seems to be a definite improvement. I also tried random move ordering.

In general ANY move ordering helps over doing nothing at all, even random move ordering. As it turns out, a good bit of the benefit is had when I put losing (non capture) move at the end of the list. But it's clear that for my program, move ordering beyond the captures and killers is a good thing and not by just a trivial amount. It's better in two ways, it searches faster and it plays better at the same depth. The only reason that it would play better is that LMR is sensitive to move ordering - even though I do not use any of this for pruning decision.

So my question is do you do ANYTHING about move ordering beyond the captures and killers etc, or just try moves in the order they are generated?

If I remember right, crafty does no explicit ordering of non-killer non-capture etc, though they come out of the move generator pseudo-ordered -- advances before retreats, etc. I wonder if that pseudo-ordering has something to do with it... perhaps the implicit ordering that's already there does enough work that HH would normally cover so the remainder is no longer beneficial.

I know the moves that come out of my movegen are in a spectacularly bad order, from highest-to lowest value pieces (king moves first, then queen, rooks, etc, with castle moves at the end). That might be another reason HH works well for some and not others.

Also I wonder... if the moves coming out of movegen are pseudo-ordered, whether it'd be beneficial to use some sort of insertion sort rather than selection sort when pulling best move to the top. In my case it doesn't since there's no pseudo-ordering to preserve

[bob]

... 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...

I have just completed a bunch of experiments with MOVE ORDERING. I'm tried using the piece square tables, full evaluation and history heuristic. I think this is what you call the "relative history heuristic" which seems to be a definite improvement. I also tried random move ordering.

In general ANY move ordering helps over doing nothing at all, even random move ordering. As it turns out, a good bit of the benefit is had when I put losing (non capture) move at the end of the list. But it's clear that for my program, move ordering beyond the captures and killers is a good thing and not by just a trivial amount. It's better in two ways, it searches faster and it plays better at the same depth. The only reason that it would play better is that LMR is sensitive to move ordering - even though I do not use any of this for pruning decision.

So my question is do you do ANYTHING about move ordering beyond the captures and killers etc, or just try moves in the order they are generated?

I do nothing after killers. My ordering is

1. hash move
2. captures with SEE >0
3. two killers
4 rest of moves with bad captures first since they were generated first.

I used to use history ordering, and it looked better slightly on position testing like WAC, ECM, etc. But when I tried it on the cluster, it was worth zero and I removed it.

[bob]

... 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...

I have just completed a bunch of experiments with MOVE ORDERING. I'm tried using the piece square tables, full evaluation and history heuristic. I think this is what you call the "relative history heuristic" which seems to be a definite improvement. I also tried random move ordering.

In general ANY move ordering helps over doing nothing at all, even random move ordering. As it turns out, a good bit of the benefit is had when I put losing (non capture) move at the end of the list. But it's clear that for my program, move ordering beyond the captures and killers is a good thing and not by just a trivial amount. It's better in two ways, it searches faster and it plays better at the same depth. The only reason that it would play better is that LMR is sensitive to move ordering - even though I do not use any of this for pruning decision.

So my question is do you do ANYTHING about move ordering beyond the captures and killers etc, or just try moves in the order they are generated?

If I remember right, crafty does no explicit ordering of non-killer non-capture etc, though they come out of the move generator pseudo-ordered -- advances before retreats, etc. I wonder if that pseudo-ordering has something to do with it... perhaps the implicit ordering that's already there does enough work that HH would normally cover so the remainder is no longer beneficial.

I know the moves that come out of my movegen are in a spectacularly bad order, from highest-to lowest value pieces (king moves first, then queen, rooks, etc, with castle moves at the end). That might be another reason HH works well for some and not others.

Also I wonder... if the moves coming out of movegen are pseudo-ordered, whether it'd be beneficial to use some sort of insertion sort rather than selection sort when pulling best move to the top. In my case it doesn't since there's no pseudo-ordering to preserve

"pseudo-ordered" is a good term. For each piece, I generate moves from most advanced destination to least advanced destination. As far as the base ordering, I generate castling, then knights, bishops, rooks, queens, kings, then pawns. Always choosing the most advanced of a piece type when there are two or more of that piece present.