[EM] Optimal Cardinal Proportional Representation

[Toby Pereira]

 Kevin
Having variable loads/costs might seem counterintuitive and unfair, but it's necessary for the Phragmén method to work at all. The default version (seq-Phragmén) minimises the maximum load on the highest loaded voter. Take the following example where A and B are two parties fielding multiple candidates:
2 voters: A1 voter: B1 voter: AB
If the load for each candidate had to be spread equally across their voters, then the only relevant voter is the AB voter. Simply electing A every time would minimise the load on this voter.
There are variants on Phragmén, including var-Phragmén, which looks at the variance of the load rather than the max on the single voter with the highest. Var-Phragmén with enforced equal loads isn't as broken as the default version would be, but it is still broken, and it would fail monotonicity. E.g.
1 voter: AB1 voter: AC
With enforced equal loading, BC is a better result than the asymmetrical AB or AC, so the extra vote for A counts against them. Electing sequentially obviously avoids this particular monotonicity failure, but it's actually quite easy to come up with examples that would also fail in the sequential case. But this shows that Phragmén's measure of balance/proportionality is non-monotonic if equal loads are enforced.
Allowing unequal loads is just another way of saying that if an approval for a candidate would count against that candidate, then we will ignore it (or count it only in part). But this leaves Phragmén with a very weak form of monotonicity. E.g.
99 voters: AB99 voters: AC1 voter: B1 voter: C
Under Phragmén philosophy, BC is a better result than AB or AC. Again, electing sequentially can save this particular case, but not in general.
If you wanted to create a tool that evaluated sets of candidates under different metrics, then PAV score (with different divisors), Phragmén variance (perhaps with equal loads enforced and not) and the standard min-max version (but only with equal loads not enforced) might be good measures to looks at.
Toby


    On Monday, 6 May 2024 at 05:11:02 BST, Kevin Venzke <stepjak at yahoo.fr> wrote:  
 
 Hi Toby,

> I posted the below on the Voting Theory Forum, but thought it might be of
> interest to some people on this list as well. The link formatting won't work
> here in the same way, but URLs can simply be copied and pasted. It should
> still read OK, and I'd be more likely to make a mess of it by changing
> everything around.

> The problem is that there are essentially two orthogonal goals for a method -
> maximising proportionality and also being properly monotonic (as well and
> passing things like [Independence of Irrelevant Ballots]
> (https://electowiki.org/wiki/Independence_of_Irrelevant_Ballots)) - and there
> was never any guarantee that they could be seamlessly combined.

I do find this interesting and will have to look into all this... I started
working on a PAV calculator but ended up finding the topic to be bigger than I
thought.

I understand the satisfaction function of Thiele's methods (sequential or just
finding the best set of winners). Discovering seq-Phragmén, I liked the concept
of candidates "costing" a fixed amount to be borne by a candidate's supporters,
but as I understand it the specific load borne by a given voter can vary, in
particular with the effect of "charging" a voter more for the election of a given
candidate precisely because that voter hadn't managed to elect anyone yet. That
doesn't strike me as fair, or reflective of anything. Maybe I misunderstand it.

One thought I had is maybe the most helpful thing would be a webpage where users
could play around with selecting sets of winners and see evaluations of those
sets by some metrics. This, as opposed to focusing on the results of specific
methods.

Not sure if you have any thoughts on what an ideal tool would do.

Kevin
votingmethods.net
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.electorama.com/pipermail/election-methods-electorama.com/attachments/20240506/8b0bcf74/attachment-0001.htm>