Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add History tables #70

Open
sroelants opened this issue Dec 5, 2023 · 0 comments
Open

Add History tables #70

sroelants opened this issue Dec 5, 2023 · 0 comments

Comments

@sroelants
Copy link
Owner

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

@sroelants sroelants changed the title Add a move history table Add History tables Dec 5, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant