History tables are very important in DiscoCheck. The reason why it's a superior technique to piece/square table is that it is dynamic. Piece/square table fo ordering quiet moves will probably work well at low depth, but eventually history (if done right) is better.Evert wrote: In Jazz I've never managed to make history (for move ordering) work. Every time I try it it's a regression. Move ordering in Jazz (without history tables) is the reasonably standard hash move/winning captures/killer moves/losing captures/quiet moves. Quiet moves are sorted according to the change in score from the piece square tables.
Regarding move ordering, what you describe sounds ok-ish, but it can be improved. Here's what I do in DiscoCheck to give an idea (for search not qsearch):
* hash move
* good captures/promotions, by descending SEE
* quiet moves: 2 killers, counter move, other quiet moves by descending history score
* bad captures/promotions by descending SEE
History table works as follows:
* history[color][piece][tsq] (reset to zero before each search)
* when a (quiet) move fails high, mark it as good by adding depth^2
* all moves that were search previously to the move that failed high are marked as bad, by susbreacting depth^2
* overflow
- cap the depth^2 bonus/malus with a constant value HistoryMax
- whenever a value exceeds, in absolute value the bound HistoryMax, divide the whole table by 2
It works very well, and the effect of having a good history table mechanism is amplified by search move count dependant (ie. history score dependant) search reductions (a.k.a. LMR).
This history method is by Tord Romstad, and was pionereed by Glaurung. It has changed a little bit in Stockfish (handling of overflows is different in SF, though the original Glaurung method worked best for me), but it's mostly the same.
I suggest you throw away all your complicated code and try that instead. Simple and general methods are always superior to hacky/complex techniques IMO.
PS: Yes, I use SEE and not MVV/LVA. I have found it works better in DiscoCheck, although MVV/LVA works better for the qsearch. As a speed optimization, I revert to MVV/LVA for ordering search captures in predicted All nodes. I'm not sure such an optimization is a good idea though: typically a compromise speed/accuracy which works well at super fast tc that I use for testing, but can backfire at long tc (i cannot measure).