captures and history heuristic

[smrf]

As far as I understood, the history heuristic distinguishes moves by source and target coordinates only, thus ignoring possible actual captures. Thus the question is, whether capture values are combined somehow to history results or not, or captures are treated seperatedly in move sort?

[bob]

As far as I understood, the history heuristic distinguishes moves by source and target coordinates only, thus ignoring possible actual captures. Thus the question is, whether capture values are combined somehow to history results or not, or captures are treated seperatedly in move sort?

When I used the history idea, I did not include captures, since they are tried early in the search, with some sort of SEE-type ordering...

[Greg Strong]

When I tried it in ChessV, I also didn't store captures, just "normal" moves, indexed by two-dimensional array [from_square][to_square]. I experimented with this a lot, and absolutely everything I tried made it play worse. I did not matter how much I weighed the history or what variant I was playing. The history heuristic was a total loser, at least as far as ChessV was concerned.

[michiguel]

When I tried it in ChessV, I also didn't store captures, just "normal" moves, indexed by two-dimensional array [from_square][to_square]. I experimented with this a lot, and absolutely everything I tried made it play worse. I did not matter how much I weighed the history or what variant I was playing. The history heuristic was a total loser, at least as far as ChessV was concerned.

And what do you use at that point? whatever the generator gives first?
I can see that history being neutral, but I wonder why it would be worse than a random pick. In other words, I wonder if you are doing something good already (that history counteracts).

Miguel

[Greg Strong]

The alternative was just piece-square-table value of the destination square - (value of source square / 2) if I recall correctly.

[michiguel]

The alternative was just piece-square-table value of the destination square - (value of source square / 2) if I recall correctly.

That makes sense. In other words, your system is better than history, which may give a negligible or at least a lower benefit.

I wonder whether your static approach can be improve even further (for instance, a bonus for tropism etc.).

Miguel

[Greg Strong]

Bonus for tropism is an interesting idea. Haven't tried it. I have been playing with move ordering a bit recently in my new engine, Quadrox. I tried adding a small bonus for moving a piece that was attacked but not defended. (I do a full eval at every node, so this information is available for free.) Much to my great surprise, this also hurt, no matter how small I made the bonus. I can't imagine why! Moving a hanging piece should be at least a little better than the typical move ...

[MattieShoes]

My history heuristic implementation doesn't affect the score of caps/promotions and caps/promotions don't affect the history table. It's also indexed by pieceType/to rather than from/to.

I have very little generic move ordering for non-captures other than history heuristic... I think there's a slight bonus/penalty for moves based on distance to the from/to square of the last move, whichever is closer. Also, I think advances are slightly favored over retreats.

I just disabled the history heuristic to see what would happen. The inclusion of the history heuristic helped in all my tests but not equally. Early on, the benefit was less than 5% faster time-to-depth. But in the endgames, it helped enormously, sometimes more than 25% faster time to depth. As always, your mileage may vary

[smrf]

Thank you all for answering!

[hgm]

When I tried it in ChessV, I also didn't store captures, just "normal" moves, indexed by two-dimensional array [from_square][to_square]. I experimented with this a lot, and absolutely everything I tried made it play worse. I did not matter how much I weighed the history or what variant I was playing. The history heuristic was a total loser, at least as far as ChessV was concerned.

In my recent Xiangqi engine I was also not able to make any variant of history work better than sorting non-captures by PST. I did use simple PST[to]-PST[from] here. Why do you divide th second term by 2? This is like adding PST[from]/2 to what I use. Do pieces hat are positioned well really have on the averag better moves than pieces that are positiond badly? I would have expected the opposite, as badly placed pieces have potentially more to gain.