[EM] how come i hadn't heard about "Meek STV" before on this list?

[Kristofer Munsterhjelm]

On 03/15/2016 10:12 PM, robert bristow-johnson wrote:
> 
> 
> ---------------------------- Original Message ----------------------------
> Subject: Re: [EM] how come i hadn't heard about "Meek STV" before on
> this list?
> From: "Kristofer Munsterhjelm" <km_elmet at t-online.de>
> Date: Tue, March 15, 2016 11:21 am
> To: rbj at audioimagination.com
> election-methods at electorama.com
> --------------------------------------------------------------------------
[snip]
>> So in short, Meek is a more complex but more fair type of STV. It isn't
>> fundamentally different from other types of STV, since its single-winner
>> version is still IRV. But it treats ballots more equally and so is
>> better than the manual methods if you can handle the complexity.
>>
> 
> it's unbelievably complex in my judgement.  i can't believe it gets as
> much traction as it does (as i found out at Stack Exchange).

I think it gets the traction it does because it's relatively simple for
a proportional candidate-based method, and like IRV, its logic seems
reasonable at first glance: you say each Droop quota's worth of voters
is entitled to one winner (no more and no less), and then you split up
the ballots into piles to enforce that.

Of course, if you consider IRV a chaotic kabuki dance (as you put it),
then the initial impression won't hold.

I get the impression that quite a few IRV advocates focus on the
workings of the method rather than on the results: not what the method
accomplishes, but how it does it. That may to some extent hold for STV
as well, although the proportionality criterion it passes limits how
weird results you can get much more than in IRV's case, since the
criterion gets tighter the more seats there are.

>>> and can we discuss Condorcet methods for multi-winner elections?
>>
>>...
>> A problem with multiwinner Condorcet methods is that they're generally
>> very complex. It's hard to come up with a multiwinner analog to the
>> Condorcet criterion,
> 
> why?
> 
> 1. start with NumRemainingCandidates = NumCandidates and
> NumRemainingSeats = NumSeats .
> 
> 2. compute the "Defeat Matrix" like you would for single winner
> Condorcet, which i still think should be triangular in shape and not
> rectangular.  everything else is determined solely from that Defeat Matrix.
> 
> 3. determine whom the top-preferred candidate is (using whatever variant
> of Condorcet you like best, Schulze, RP, minmax, margins, winning votes,
> whatever to resolve any cycle).
> 
> 4. elect that person and eliminate that person from the set of
> candidates.  decrement both NumRemaningCandiates and NumRemainingSeats by 1.
> 
> 5. with the set of remaining candidates, if NumRemainingSeats > 0 go to
> step 3.  else end and pack up the ballots into the ballot bag and seal it.
> 
> how hard is that??
> 
>  
> 
> and here is what we tell voters how the system works.  first this is
> what we tell them for single winner:
> 
> "If more voters prefer Candidate A over Candidate B than vise versa,
> then do not elect Candidate B."
> 
> with  multiwinner races, simply add four words at the end getting
> 
> "If more voters prefer Candidate A over Candidate B than vise versa,
> then do not elect Candidate B before electing Candidate A."
> 
> who can argue with that?

Suppose we replace Plurality per constituency with a repeated election
method that goes like this: first, conduct a Plurality election for the
whole state, then elect the winner and redo the election. Do so until
you've filled as many seats as you need.

If there's a coherent majority that supports a particular party P, the
method  will amplify majority into unanimity. The majority first votes
for say, P1. By the majority criterion, it gets P1. In the second round,
the majority votes for P2. It gets P2. And so on until every seat is filled.

Every method would amplify majority into unanimity in that manner,
including the Condorcet extension you've described. For Condorcet, it is
actually worse. If the method is cloneproof (and it should be), then if
the winner is part of party A, and no voter votes across party lines
(e.g. first candidate A1, then candidate B1, then candidate A5), then
party A would fill the whole assembly.

If the method is Plurality, Plurality behaves about as unpredictably as
you'd expect, and the result is you get kinda-sorta proportional
representation  as long as all the voters use the right strategy. But
for more well-behaved single-winner methods, the effect is kind of like
replacing single member Plurality with bloc voting: it hurts minority
representation. A cloneproof method will rank every clone of the winner
in order after the winner before it gets to a non-clone.

The usual way to deal with that kind of problem is to use single-winner
districts. If, say, the state is 40% right-wing and 60% left-wing, the
distribution may end up so that 40% of the districts have a right-wing
majority and 60% have a left-wing majority, and then the single-winner
method works properly in each district and you get a balanced assembly.

But through either bad luck or malice (gerrymandering), the statistical
assumption may not hold. Then the reasoning fails and groups of voters
may fail to be represented at all, or may conversely be represented far
in excess of their real support. Condorcet is better than Plurality here
because it handles situations with no single majority faction better,
but Condorcet also implies the majority criterion, so incorrect
representation can still happen.

Multiwinner methods like STV try to directly infer from the ballots what
sort of groups exist and then give each of their candidate groups
representation proportional to their support. You could say that they
try to find the optimal gerrymander from the point of view of all the
voters.

And that's why they're generally much more complex than their equivalent
single-winner methods: they have to do two things at once. First, they
have to elect good winners from the point of view of the voters as a
whole. Second, they have to give different groups their fair share of
the seats. These objectives pull in opposite directions; e.g. say a
significant number of left-wing voters like a candidate who the rest of
the voters loathe. How wide support inside the group balances out how
much general loathing?

It can be hard to know what kind of winners STV will pick in general,
since it shares IRV's logic, but in a similar way to how all Condorcet
methods pass the Condorcet criterion, usually there's one criterion one
considers the method to have to pass to be proportional in the STV
sense; and STV passes it. The criterion is the Droop proportionality
criterion: if more than k * 100/(s+1) % of the voters rank a certain
group of candidates before everybody else (not necessarily in the same
order), then at least k of those candidates should be elected.

Ordinary STV decides which of the candidates in the group should be
elected by, in essence, IRV within the group, so it's not all that good.
Schulze STV also passes the same criterion, but is Condorcet-based. It
is also *very* complex.

>> so usually what the methods do (like Schulze STV)
>> is compare *assemblies* as if they were candidates in a Condorcet method
>> (e.g. "elect A, B, and C" beats "elect B, C, and E" pairwise). But since
>> there are up to (numcands choose numseats) of these assemblies, it can
>> get unwieldy fast.
> 
> i don't see why it would have to.

It may not have to - there may exist Condorcet methods that extend the
Condorcet logic to multiwinner while obeying some proportionality
criterion. Comparing assemblies is just the most intuitive way to extend
the Condorcet logic. Matrix-based Condorcet methods could be seen as
comparing pairs of propositions (i.e. "Elect A" vs "Elect B") and
determining which proposition wins every hypothetical runoff.
Assembly-comparison methods makes the propositions into "The assembly
shall consist of A, B, C", "The assembly shall consist of B, C, and E"
and so on.

I think the problem is that we don't have a good proportional extension
of the Condorcet criterion for multiwinner systems. So most Condorcet
multiwinner methods are constructed to follow these properties:

- The method should reduce to some kind of Condorcet method when the
size of the assembly is one (i.e. single-winner) and be well-behaved in
this case (monotone, cloneproof, whatever).
- The method should pass some proportionality criterion (usually the
Droop proportionality criterion) in the multiwinner case.
- The method might also pass other multiwinner criteria (e.g. resistance
to vote management for Schulze STV).

Assembly-comparison is just a relatively easy way to pass multiwinner
criteria as if they were singlewinner criteria, or to make use of a base
method's single-winner criterion compliance for multiwinner purposes.

> sorry to sound like a Condorcet partisan, but i am that.  especially
> after our experience in Burlington Vermont in 2009 and 2010.

I have an idea of a computationally simpler Condorcet multiwinner method
based on MAM/RP, but I'm kind of stuck on a particular point. Perhaps I
can mention it later in case others can see how to fix it.

But in the absence of such, I'd suggest that Condorcet methods be used
in single-winner districts rather than multiwinner "en bloc".
Redistricting then becomes an issue, so I'd suggest either an
independent redistricting commission, or some kind of MMP/biproportional
system to even out imbalances.

Bloc Condorcet voting might be useful for preventing kingmaker scenarios
in proportional representation assemblies. Suppose a 2% party can decide
which coalition wins by deciding which to support. That 2% party then
has undue power. But if 2% of the representatives are elected by
Condorcet based on a large area, these would be broad support winners
(due to how Condorcet works) and the strategy wouldn't work. Something
like Accurate Democracy's ensemble councils
(http://www.accuratedemocracy.com/e_intro.htm), but on a larger scale. A
similar effect could be had by doing single-member district voting with
much larger districts for the balancing seats, though.