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

[FEATURE] Use PSQTs during move ordering #68

Open
2 tasks
dannyhammer opened this issue Nov 9, 2024 · 2 comments
Open
2 tasks

[FEATURE] Use PSQTs during move ordering #68

dannyhammer opened this issue Nov 9, 2024 · 2 comments
Labels
enhancement New feature or request

Comments

@dannyhammer
Copy link
Owner

dannyhammer commented Nov 9, 2024

Description:
During move ordering, moves are currently given a "base score" that is modified through move ordering techniques such as MVV-LVA and (once #67 merges) History Heuristic.
Instead of assigning the same "base score" to all moves, give each move an initial score based on their PSQT value. After all, PSQTs are (currently) the only way that the eval function can tell whether two positions of equal material are better/worse than each other. The intent here is to make it so that "bad" moves (from a static eval's perspective) get ordered last, and therefore can be pruned easier. This would, of course, require that the PSQT's score does not interfere with any existing move ordering heuristics.

I believe the code would be as simple as adding the following in the Search::score_move method:

score += PSQT[piece][mv.to()] - PSQT[piece][mv.from()];

As an example, using the current PSQTs in the engine, the move Nf3 would receive a score of:

PSQT[WhiteKnight][f3] - PSQT[WhiteKnight][g1] = 337 - 301 = 36

Requirements:

  • Set a move's "base score" to be it's PSQT value
  • Ensure that PSQT scores cannot be greater than scores from History Heuristic or other move ordering heuristics
@dannyhammer dannyhammer added the enhancement New feature or request label Nov 9, 2024
@dannyhammer
Copy link
Owner Author

On further investigation, it appears this will be more difficult than expected.

The problem lies in the fact that PSQTs for individual pieces have both middle-game and end-game tables. So, in order to interpolate between these two tables, we need an endgame weight. Currently, that's only obtainable after constructing an Evaluator instance. It would be expensive to construct an Evaluator just to aid in scoring the moves. It might be worth it- I don't know how much Elo this feature would gain.

I would suggest shelving this issue for now, until we have internal board representation (rather than using chessie).

dannyhammer added a commit that referenced this issue Nov 10, 2024
Honestly? I'm not entirely sure why this made a difference at all. Let
alone a positive difference.

I suspect this difference will go away with #28, #68 or other features
that affect move ordering.

---
SPRT:
```
Elo   | 12.65 +- 9.54 (95%)
SPRT  | 8.0+0.08s Threads=1 Hash=16MB
LLR   | 3.00 (-2.94, 2.94) [0.00, 10.00]
Games | N: 3600 W: 1497 L: 1366 D: 737
Penta | [226, 255, 752, 296, 271]
```
https://pyronomy.pythonanywhere.com/test/127/

bench: 11371856
@dannyhammer
Copy link
Owner Author

I've tried this twice now with little success.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant