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
Someone should go through the code to make sure that the satisfaction mechanism works as intended on multiprofiles. It probably does but I have some doubts that everything is correct.
Handle Counter properly
For the entities inheriting from Counter (Multiprofile), some things do not go through. For instance check_dict_members fails in the tests (see tests/test_class_inheritence.py line 415). This should not fail so it needs to be fixed.
Clean implementation of the FrozenCardinalBallots
So far we're using a dirty trick: inherit from dict and force the set_item method to fail.
Implement non-supporters paying in Method of Equal Shares
Add a Boolean flag that allows non-supporters to pay. This is useful for explanation purposes.
Implement a general mechanism that takes a Satisfaction class as parameter and normalises it or relativises it. So when satisfaction is asked, divide by the max achievable satisfaction.
Implement bounds in Greedy Welfare
For greedy welfare, implements the idea that you stop considering voters that have exceeded a certain. That is useful for instance for Chamberlin-Courant. Poses many questions: How to pass the bounds? As a dict from ballot to bound, but then we need a unique identifier for the ballots which we don't have so far. Should the bounds be on the satisfaction? We could have a saturation_point parameter for Satisfaction that indicates when a ballot should not longer be considered etc...
Extends Coehsiveness to Multiprofiles
So far the content of analysis/cohesiveness does not support Multiprofile. That needs to be implemented.
Cast profiles from one type to another
Implement methods to cast profiles, for instance ApprovalProfile.to_cardinal where projects are given scores 0 and 1. This can be used to test rules, for instance that MES(profile) returns the same as MES(profile.to_cardinal).
The text was updated successfully, but these errors were encountered:
Current Implementation
Write the docs for the analysis module
This needs to be populated properly: https://comsoc-community.github.io/pabutools/usage/analysis.html.
Satisfaction and multiprofiles
Someone should go through the code to make sure that the satisfaction mechanism works as intended on multiprofiles. It probably does but I have some doubts that everything is correct.
Handle Counter properly
For the entities inheriting from Counter (Multiprofile), some things do not go through. For instance check_dict_members fails in the tests (see tests/test_class_inheritence.py line 415). This should not fail so it needs to be fixed.
Clean implementation of the FrozenCardinalBallots
So far we're using a dirty trick: inherit from dict and force the set_item method to fail.
Implement non-supporters paying in Method of Equal Shares
Add a Boolean flag that allows non-supporters to pay. This is useful for explanation purposes.
Import from PrefLib
Export to PrefLib functions are there but not import. Take inspiration from what we did with abcvoting: https://github.com/martinlackner/abcvoting/blob/master/abcvoting/fileio.py.
Further Development
Implement the Maximin Support Rule, see #21
Implement max Chamberlin-Courant rule
Re-Define Normalised and Relative satisfaction
Implement a general mechanism that takes a Satisfaction class as parameter and normalises it or relativises it. So when satisfaction is asked, divide by the max achievable satisfaction.
Implement bounds in Greedy Welfare
For greedy welfare, implements the idea that you stop considering voters that have exceeded a certain. That is useful for instance for Chamberlin-Courant. Poses many questions: How to pass the bounds? As a dict from ballot to bound, but then we need a unique identifier for the ballots which we don't have so far. Should the bounds be on the satisfaction? We could have a saturation_point parameter for Satisfaction that indicates when a ballot should not longer be considered etc...
Extends Coehsiveness to Multiprofiles
So far the content of analysis/cohesiveness does not support Multiprofile. That needs to be implemented.
Cast profiles from one type to another
Implement methods to cast profiles, for instance ApprovalProfile.to_cardinal where projects are given scores 0 and 1. This can be used to test rules, for instance that MES(profile) returns the same as MES(profile.to_cardinal).
The text was updated successfully, but these errors were encountered: