-
Notifications
You must be signed in to change notification settings - Fork 8
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
Refactor MSR Banzhaf valuation #605
Conversation
I clarified the documentation of I think it would be clearer if we only expose the square root of the variances as |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just looked over the files, seems all good to me at first glance. I did not run any code or tests yet though, so no way to be sure for me. Also the CI is not running for this branch. Are we updating the notebooks for the new valuation structure as well or is this planned at a later stage? Looking at notebooks may help to verify that everything works as expected.
I am not aware of the current plans about notebooks etc. so feel free to ignore me if there are any decisions that I am unaware of.
… - rename file to target-name
… - rename source-file to git-split-temp
… - resolve conflict and keep both files
… - restore name of source-file
Co-authored-by: Kristof Schröder <[email protected]>
Co-authored-by: Kristof Schröder <[email protected]>
Description
This PR implements Maximum Sample Re-use (MSR) Banzhaf valuation in the new architecture. The implementation deviates strongly from the previous implementation and fixes a bug in the variance estimation.
The new implementation uses two
ValuationResult
instances to keep track of the positive and negative running means. After each update, those are combined into the final result object. The update counter of the combined result is set to the minimum of the two update counters. The variance of the combined result is set to the sum of variances (assuming independence).Open questions
nan
is safer. Note that if the update counter is defined as suggested above, this situation can be completely avoided by usingMinUpdates
as stopping criterion.inf
.Checklist