Improving the MUtility function #1929
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
I found the old mutility lacking and I know its not giving the best m-effect to the best possible moves with higher q and lower mlh.
More comments
comment
changing defaults.
another mistake fixed.
To skip contempt if playing as black and eval negative.
Final defaults maybe before a tune.
Using the MUtility wrap again.
quick bug fix.
New mutility implemetation
borg323
reviewed
Nov 9, 2023
fix bad logic.
Don't know why I changed it.
Stalling engines fix.
Update search.cc
Re-simplifying the GetMUtility code. Was very confused by some of the logic, hence why I overcomplicated the code.
Master commits.
|
To proceed, this change at least needs to show that it doesn't cause Elo or nps regression. And preferably, also some better math-grounded justification for the changes, maybe discuss with @Naphthalin as he is the author of the original MUtility. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In this PR I'm introducing 2 new tune able parameters, only the MovesLeftThreshold parameter is left from the old MUtility function. What this PR will do is prioritize shorter wins and longer losses.
The first parameter is MovesLeftMidpointMove this controls where the m-value crosses the y-axis as in moves with greater value than this parameter will have a negative m-effect value. This is done so moves that have shorter movesleft-value than MovesLeftMidpointMove can be prioritized higher than moves with longer movesleft-value than MovesLeftMidpointMove I would recomend (100) for this parameter.
The second parameter is the MovesLeftSteepnessFactor this should be the more tune-able parameter to match hardware as this parameter will differ depending on the nps. This sets the steepness of the curve, which is how quickly the m-value changes as the moves-left decrease or how high or low the m-value goes in simple terms. The higher this value is the greater the m-effect on node Q which might cause aggressive play and missing some deeper tactic's that might cause losses.