[EM] FairVote comment on Burlington dumping IRV

Abd ul-Rahman Lomax abd at lomaxdesign.com
Wed Jul 3 14:37:12 PDT 2013


At 12:31 AM 7/3/2013, Jameson Quinn wrote:
>Abd, I noticed something. I don't want to jump to any conclusions, 
>so I'm asking you directly.
>
>2013/7/3 Abd ul-Rahman Lomax <<mailto:abd at lomaxdesign.com>abd at lomaxdesign.com>
>... Bucklin ...
>
>
>  You said "Bucklin", not "EMAV". So, two questions and a comment:
>
>Q1. Why did you change?

EMAV is not a known method, it's brand new, I just announced it, and 
this is a general post, not about details about the specific method.


>Q2. Is there anything that would convince you to switch to saying "MAV"?

Not in that context, not yet.

>Comment: To me, "Bucklin" is not a system, but a class of systems; 
>at a minimum, it would include all different Progressive-era systems 
>which were called "Bucklin" at the time, but to me, it includes all 
>descending-approval-threshold-until-majority systems (including for 
>instance MJ, GMJ, MCA, and MAV.)

My comments were referring to the class of systems, but also 
specifically to Bucklin -- which primarily means those early systems 
-- and FairVote propaganda was about "Bucklin."

Of course I'd love to promote EMAV, but promotion is not my primary goal.

The subject post was written to review Richie's response to the 
Burlington debacle, and traditional Bucklin -- say, three-rank, 
mandatory single votes in first and second rank, almost exactly the 
same as some of the old implementations -- would have fixed the 
Burlington problem easily. That does *not* mean that this would be ideal.

As to MAV, I'd support it if the "regression" were *necessary.* I 
don't see it as that, and the fallback to higher preferences clearly 
moves away from maximizing expressed utilities.

I understand that it was frustrating for you that I appeared to 
support MAV, for a short time, but I think that we were pandering to 
some shallow arguments, that we don't need to avoid the "chicken 
dilemma," and that using the range ratings adequately addresses the concern.

I.e.:

original Bucklin: with a multiple majority, all at or above the found 
majority rating are collapsed to approval. Same with majority 
failure. The result is that a lower preference may count *the same* 
as a higher one. It's the "approval problem"

MAV: under the multiple majority at a lower preference rule, the 
system ignores the lower preference votes, using only higher-level 
approval information. It does count the lower preference votes, but 
not to distinguish between those candidates. I haven't done so, but I 
could show some problem scenarios. It solves the "approval problem," 
but at the cost of apparent expressed utility.

EMAV: The system uses all the votes in the two cases (multiple 
majority and majority failure.) Thus lower preference votes do count, 
but only at deprecated value. The difference between full preference 
and minimal approval is 1/2 vote. The difference between full 
prefeence and the below-approval rank that is above maximum 
opposition is 3/4 vote. So EMAV is intermediate to original Bucklin and MAV.

The attempt to fix on a consensus method, on the CES list, was 
premature. The voting done was premature. Ad-hoc list process can do 
this: it can start to vote on something before the discussion is 
complete. Basic democratic process: there is no vote until there is a 
*supermajority* declaring that the question is fixed and agreed upon 
and it's time to vote. 




More information about the Election-Methods mailing list