[EM] Holy grail: PAR with FBC?

[C.Benham]

On 11/11/2016 2:09 AM, Jameson Quinn wrote:

> If the number of uncounted ballots is enough to sway the election 
> using a threshold, it has every chance of being enough to sway the 
> election without thresholds.

Not necessarily.  Very close contests are unavoidable, but thresholds 
add further possible problems.

Suppose it is wrongly assumed that the total number of valid ballots is 
known and the votes are counted and X is declared the apparent winner. 
Suppose that X
is by far the most approved (i.e. most Prefers + Accepts) candidate (and 
say for good measure the CW) but X only very narrowly makes the 25% 
threshold of Prefers.

Now say that a few extra ballots are discovered, all of which give 
Accepts to X and Prefers to only nobodies and maybe some Rejects to Y, 
with the result that X no longer makes the
25%  threshold and Y wins.  How do you think that will go down?

> My thinking was that in most real-world situations, you'd only have to 
> check one prefer and one reject to get maximum effectiveness, and it 
> would be obvious which to reject.
>
> But I see your point. So I'm changing the method to: "Default is 
> reject for voters who do not explicitly reject any candidates, or 
> accept for those who do." 

That is a step in the right direction, but now you have the potential 
weirdness of blanks meaning different things on different ballots. 
Suppose on one ballot a single candidate
is definitely Preferred  and all but one other candidate are definitely 
left blank. But for the last candidate it is disputed whether it was 
left blank or was given a Reject.

If blanks all mean the same thing, then the dispute only affects that 
one candidate. But with your proposal it also affects all the candidates 
left definitely blank.

Chris Benham


>
>
> 2016-11-10 9:04 GMT-05:00 C.Benham <cbenham at adam.com.au 
> <mailto:cbenham at adam.com.au>>:
>
>>     1. Voters can Prefer, Accept, or Reject each candidate. Default
>>     is Accept.
>
>     This seems to assume that all the voters are interested in all the
>     candidates and like checking boxes, whereas
>     I should think that a lot of voters would be only interested in
>     their favourite and content to keep voting the
>     way they did under plurality (and would presumably continue to do
>     so under Approval).
>
>     They should be allowed to continue giving the most effective vote
>     possible by simply giving a "Prefer" rating to their
>     favourite.  In-effect penalising such voters for forgetting to
>     also give "Rejects"  to all their non-favourites is unfair
>     and dumb.
>
>     It will give voters who aren't fans of the new method extra reason
>     to resent it.  Suppose that a strong candidate
>     from an established party very narrowly loses just because some of
>     his/her supporters forgot to give out "Rejects".
>     Don't you think that might fuel a movement to dump the method?
>
>
> My thinking was that in most real-world situations, you'd only have to 
> check one prefer and one reject to get maximum effectiveness, and it 
> would be obvious which to reject.
>
> But I see your point. So I'm changing the method to: "Default is 
> reject for voters who do not explicitly reject any candidates, or 
> accept for those who do."
>
>
>>     2.Candidates with a majority of Reject, or with under 25% Prefer,
>>     are eliminated, unless that would eliminate all candidates.
>
>     I don't like arbitrary thresholds.  Obviously this causes failure
>     of Irrelevant Ballots Independence. But also there is the problem
>     that the final exact number of valid ballots can be disputed
>     and/or take quite a while to establish.
>
>     Postal votes can take a while to come in, or may be mislaid and
>     later found. The validity of certain ballots can be disputed and
>     the subject of legal proceedings.  Some people might have
>     initially been denied the right to vote, but then succeed in
>     having that
>     over-turned and are then allowed to vote.
>
>     It is much better if the algorithm just (more-or-less directly)
>     compares the candidates with each other rather than measure them
>     against
>     arbitrary percentage-of-the-votes thresholds.
>
>
> If the number of uncounted ballots is enough to sway the election 
> using a threshold, it has every chance of being enough to sway the 
> election without thresholds. Only under the assumption that all 
> uncounted ballots are irrelevant does your objection apply 
> particularly to threshold methods.
>
> ...
>
> I'm giving up on the method I'd proposed earlier. It's now called 
> "CPAR", for Complicated PAR. But I do have a new patch to PAR to make 
> it pass FBC:
>
>  1. Voters can Prefer, Accept, or Reject each candidate. Default is
>     "Accept"; except that for voters who do not explicitly reject any
>     candidates, default is "Reject". Voters can also mark a global
>     option that says: "I believe that voters like me should be the
>     first to compromise."
>  2. Candidates with a majority of Reject, or with under 25% Prefer,
>     are eliminated, unless that would eliminate all candidates. If a
>     candidate would have been eliminatable considering all the
>     "prefer" votes they got on "compromise" ballots as "rejects", then
>     they are considered "eager to compromise"
>  3. The winner is the non-eliminated candidate with the highest score.
>     Candidates score 1 point for each voter who prefers them, and 1
>     point for each voter who accepts them and prefers only candidates
>     who were eliminated or eager to compromise.
>
> The above method meets FBC, except in vanishingly rare cases where 
> multiple candidates are simultaneously at a threshold (analogous to 
> perfect ties).
>
> No virus found in this message.
> Checked by AVG - www.avg.com <http://www.avg.com>
> Version: 2016.0.7859 / Virus Database: 4664/13383 - Release Date: 11/10/16
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.electorama.com/pipermail/election-methods-electorama.com/attachments/20161112/392d0c84/attachment-0001.htm>