Move ordering improvements

[BB+]

I seem to remember Vas saying something similar, that the idea was simply ineffective. But until all options are exhaustively tested and rejected, there is always hope, however slight...

I think one of the problems is that there is little guidance as to why some variation of this idea might work, so you are really just stabbing in the dark. This plus the fact that any gains would be slight compared to time needed to find good parameters. Schaeffer could at least give some "highbrow" reasoning for his method, but with the change in tree shapes over 2.5 decades, it no longer retains much validity.

[Mecnels]

What seems to work fine for me atm
is incrementing counters in two separate tables:
(a) standard 'history' table for 'good' moves (either a beta cutoff or local maximum of an all-node)
(b) a 'blunder' table for most moves which are worse by BLUNDER_DELTA centi-pawns than a current local maximum of a node
For this to work it's also important to prefer a fail-soft alpha-beta tree, so that a parent node gets more accurate informations from its child node
(e.g. by how much worse (at least) was the move than the local maximum.
When doing the move ordering I'll use the relation of the move's 'good' vs. its 'blunder' history,
e.g. A move with a +100 in its 'good' history table and a +0 in its 'blunder' history table will be searched before
a move with a +0 'good' and a +100 'blunder' counter.
Also, a move with a +20 'good'/+5 'blunder' history is considered to be equally good as a +4/+1 move.
Before that I only used the 'positive' history table (without the blunder statistics) for move ordering, which didn't peform too well.
Since I added the blunder statistics (to support & complement the +history table), my engine only needs to analyze ~25% of the nodes.
(I remember a complex midgame situation when my old version (no blunder-table, fail-hard alpha beta) searched ~48 Mio. Nodes,
whereas my new version with the blunder-table +fail-soft alpha-beta only needed to search ~11 Mio. Nodes - for the same result.)
[Of coures the fail-soft alpha-beta gametree has several other benefits, too. (especially the scores of hash-moves helped me with guessing better bounds
for node-local aspiration windows).]

[hyatt]

What seems to work fine for me atm
is incrementing counters in two separate tables:
(a) standard 'history' table for 'good' moves (either a beta cutoff or local maximum of an all-node)
(b) a 'blunder' table for most moves which are worse by BLUNDER_DELTA centi-pawns than a current local maximum of a node
For this to work it's also important to prefer a fail-soft alpha-beta tree, so that a parent node gets more accurate informations from its child node
(e.g. by how much worse (at least) was the move than the local maximum.
When doing the move ordering I'll use the relation of the move's 'good' vs. its 'blunder' history,
e.g. A move with a +100 in its 'good' history table and a +0 in its 'blunder' history table will be searched before
a move with a +0 'good' and a +100 'blunder' counter.
Also, a move with a +20 'good'/+5 'blunder' history is considered to be equally good as a +4/+1 move.
Before that I only used the 'positive' history table (without the blunder statistics) for move ordering, which didn't peform too well.
Since I added the blunder statistics (to support & complement the +history table), my engine only needs to analyze ~25% of the nodes.
(I remember a complex midgame situation when my old version (no blunder-table, fail-hard alpha beta) searched ~48 Mio. Nodes,
whereas my new version with the blunder-table +fail-soft alpha-beta only needed to search ~11 Mio. Nodes - for the same result.)
[Of coures the fail-soft alpha-beta gametree has several other benefits, too. (especially the scores of hash-moves helped me with guessing better bounds
for node-local aspiration windows).]

How can you get this "blunder delta"??? You only get values within alpha/beta window. Fail-soft you say? Not good enough. At any node, you only need a move "good enough" to produce a cutoff and show the move at the previous ply is bad, you don't need the "best move" that accurately shows how bad the move at the previous ply is. So I do not see how you can do this "blunder history" with any degree of accuracy at all...

[Mecnels]

What seems to work fine for me atm
is incrementing counters in two separate tables:
(a) standard 'history' table for 'good' moves (either a beta cutoff or local maximum of an all-node)
(b) a 'blunder' table for most moves which are worse by BLUNDER_DELTA centi-pawns than a current local maximum of a node
For this to work it's also important to prefer a fail-soft alpha-beta tree, so that a parent node gets more accurate informations from its child node
(e.g. by how much worse (at least) was the move than the local maximum.
When doing the move ordering I'll use the relation of the move's 'good' vs. its 'blunder' history,
e.g. A move with a +100 in its 'good' history table and a +0 in its 'blunder' history table will be searched before
a move with a +0 'good' and a +100 'blunder' counter.
Also, a move with a +20 'good'/+5 'blunder' history is considered to be equally good as a +4/+1 move.
Before that I only used the 'positive' history table (without the blunder statistics) for move ordering, which didn't peform too well.
Since I added the blunder statistics (to support & complement the +history table), my engine only needs to analyze ~25% of the nodes.
(I remember a complex midgame situation when my old version (no blunder-table, fail-hard alpha beta) searched ~48 Mio. Nodes,
whereas my new version with the blunder-table +fail-soft alpha-beta only needed to search ~11 Mio. Nodes - for the same result.)
[Of coures the fail-soft alpha-beta gametree has several other benefits, too. (especially the scores of hash-moves helped me with guessing better bounds
for node-local aspiration windows).]

How can you get this "blunder delta"??? You only get values within alpha/beta window. Fail-soft you say? Not good enough. At any node, you only need a move "good enough" to produce a cutoff and show the move at the previous ply is bad, you don't need the "best move" that accurately shows how bad the move at the previous ply is. So I do not see how you can do this "blunder history" with any degree of accuracy at all...

Yeah, but as long as the move ordering of my child nodes is good enough to return its best (or close-to-best) 'beta' refutation of the parent node's blunder,
the returned (fail-soft) bound (local maximum of the child) will give the parent this valuable info whether its last move was a 'little' blunder
(say ~5 centipawns worse than the current local maximum of the parent), or whether it's really so bad that the counter of the blunder table must be incremented
(so that other nodes in the future are warned and won't try a move with a chance of being a blunder too early).
It's basically my attempt of doing a 'relative' history ordering -> compare the positive (verified best-move or beta-cutoff) to the blunder statistic of a move, and
order it accordingly. I was surprised, too, that the number of searched nodes dropped so massively by using that blunder-table in addition to the standard history array,
didn't expect that.