# [EM] Preferential Party-List Proportional Representation (PPLPR)

Kristofer Munsterhjelm km_elmet at t-online.de
Fri Oct 31 15:13:33 PDT 2014

```On 10/31/2014 10:52 PM, Vidar Wahlberg wrote:
> Some of you may remember that I once brought up the topic of a
> party-list voting system with preferential votes. Unfortunately I've not
> found much information about such systems, so on a couple occasions I've
> tried creating such a system myself. Last time I wrote about it on this
> list my attempts at creating a such system did not lead to anything
> useful, but a couple weeks ago I thought of another approach to the
> problem. This lead to a system I've called "Preferential Party-List
> Proportional Representation" (or PPLPR for short). Now I'd like you to
> take a look at the system, and point out flaws and weaknesses.

From a very brief look at it (particularly since you gave the LCR
example), it seems like your method passes house monotonicity. You end
up with percentages which I assume you then run through something like
Sainte-Laguë to get actual seat allocations.

But in that case, the fork of LCR will mean that

- either you don't elect C in the one-seat case

o4

- you elect C plus someone else in the two-seat case,

neither of which is preferable.

One-seat and two-seat elections are kinda extremes for multiwinner
methods, but driving them to edge cases can reveal otherwise subtle
problems more easily.

I'd also say that IMHO, if every voter ranks {A, B, C} next to each
other (i.e. never rank some other party in between), and you replace
this with some party X (e.g. if someone votes D > A > B > C > E, then
the replaced ballots become D > X > E), then X should have the same
support as {A, B, C} had in total. Both small-party and large-party bias
is bias, after all. But making cloneproof methods can be pretty tricky,
so if you'd consider trying to do that now to be premature optimization,
I'd understand that :-)
```