You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Now that we've added the Q search, I'm even more keen to push the move ordering as far as we can take it.
Most of these history tables are in the same vein as the killers table: keep a record across subtrees of moves that caused cutoffs in one way or another.
History table
A table indexed by [piece][to_sq] that we increment whenever a move causes a beta cuttoff. The score is a decreasing function of ply (increasing function of remaining_depth, so bonuses acquired close to the root are favored. (Since the positions blow up deeper down the tree, where the history is likely to be less relevant because too much has happened in between, we want to decrease their impact on the score).
Also, if the move caused a beta-cutoff, any moves we inspectead before it that didn't cause a cutoff get a penalty subtracted from their score.
Countermove table
A table, also indexed by [piece][to_sq], but this time tracking the opponent's moves.
There's two approaches we can take, here. Either we have a massive [piece][to][piece][to] table that we can assign individual scores, for very granular scoring, or we can have a simple [piece][to] table that stores a single move, but we have no guarantee that it's necessarily "the best" move.
I wonder if we should store beta along with the move, and only update it if the beta was larger than the one stored. I imagine that would just turn into random noise, though, as we move deeper down the search tree...
Alpha improvements
Also be good to keep track of moves that improve alpha, because they have a higher likelihood of becoming PV moves. Not a huge improvenement, probably, but a pretty low-effort change nonetheless.
The text was updated successfully, but these errors were encountered:
sroelants
changed the title
Add a move history table
Add History tables
Dec 5, 2023
Now that we've added the Q search, I'm even more keen to push the move ordering as far as we can take it.
Most of these history tables are in the same vein as the killers table: keep a record across subtrees of moves that caused cutoffs in one way or another.
History table
A table indexed by
[piece][to_sq]
that we increment whenever a move causes a beta cuttoff. The score is a decreasing function ofply
(increasing function ofremaining_depth
, so bonuses acquired close to the root are favored. (Since the positions blow up deeper down the tree, where the history is likely to be less relevant because too much has happened in between, we want to decrease their impact on the score).Also, if the move caused a beta-cutoff, any moves we inspectead before it that didn't cause a cutoff get a penalty subtracted from their score.
Countermove table
A table, also indexed by
[piece][to_sq]
, but this time tracking the opponent's moves.There's two approaches we can take, here. Either we have a massive
[piece][to][piece][to]
table that we can assign individual scores, for very granular scoring, or we can have a simple[piece][to]
table that stores a single move, but we have no guarantee that it's necessarily "the best" move.I wonder if we should store
beta
along with the move, and only update it if thebeta
was larger than the one stored. I imagine that would just turn into random noise, though, as we move deeper down the search tree...Alpha improvements
Also be good to keep track of moves that improve alpha, because they have a higher likelihood of becoming PV moves. Not a huge improvenement, probably, but a pretty low-effort change nonetheless.
The text was updated successfully, but these errors were encountered: