[EM] Re: auto-truncation

[Araucaria Araucana]

On 22 Apr 2005 at 18:42 UTC-0700, Russ Paielli wrote:
Araucaria Araucana araucaria.araucana-at-gmail.com |EMlist| wrote:
>
>> Consider this case.  Original true preferences:
>>   27: A>B
>>   24: B>A   49: C
>> A is the Condorcet winner.  Now consider what happens if B defects
>> via
>> truncation:
>>   27: A>B
>>   24: B
>>   49: C
>> Under RP(wv), Beatpath(wv) or DMC, B wins.  B voters have gotten a
>> better result by dropping a lower preference.  This is an example of
>> the "Later No Hurt" violation of Condorcet completion methods -- B
>> voters hurt their favorite by adding a lower-ranked preference.
>> But if A puts the approval cutoff above B, B can't win in DMC:
>>   27: A>>B
>>   24: B
>>   49: C
>> C wins, anyway you cut it, as you found.  There's no LNHurt
>> situation
>> here because B can't win either way.  So the best the B voters can do
>> is to add a preference for A.  That's what I mean by the poison pill
>> (by the A voters).  Is it clear now?
>
> Ahhh...yes, now I see what you meant. As you pointed out, however,
> this particular situation is apparently no worse for DMC than it is
> for popular (on EM) Condorcet methods (or Approval). Are you saying
> that, with an approval cutoff (i.e., ranking allowed for unapproved
> candidates) that DMC actually has an advantage over those Condorcet
> methods? If so, then I am certainly willing to reconsider allowing
> an approval cutoff.

Yes, I am saying that this is a major advantage for DMC.

It has the same effect as ATLO, but does not require a recount.

AWP has the same advantage.  But AWP requires an extra pairwise array
for the strong preference votes.

You should actually try reading James' papers on CWP and AWP -- the
extra AWP array is actually the same as DMC's with all above-cutoff
votes and below-cutoff votes set to equal-rank.

I actually think AWP would be an excellent proposal (say along the
lines of Jobst's "grand compromise").  I just worry about the
complexity of implementation.

>
> Note, however, that the added equipment requirement for an approval
> cutoff could delay the adoption for decades, but I won't get into
> that now.

Or you could add an extra "candidate" to set the cutoff level.  No new
equipment.

>
> Let me just suggest another possible approach to the problem:
> auto-truncation. This idea is probably unoriginal, and it is also
> probably meritless, but let just throw it out there anyway as a long
> shot. This idea could be applicable to other methods too, but lets
> just consider DMC/RAV.
>
> Suppose we determine a tentative winner using the standard DMC
> rules.  Now we "suppress" (tentatively eliminate) all the
> non-first-choice votes for that tentative winner, then determine a
> new winner. For all the voters who had the new winner ranked above
> the previous tentative winner, keep that previous winner
> "suppressed", but for all who didn't, unsuppress (restore) the votes
> for the previous winner. Repeat until the process converges to a
> stable winner.
>
> Will this procedure always converge? If so, has it been proposed
> before, and is it equivalent to some other, perhaps simpler, method?

Is this procedure summable?  It sounds like it requires recounts.

>
>
>> So a good DMC strategy is
>>    Rank all candidates you are willing to see elected, from your
>>    favorite to your "hold-your-nose-and-swallow-just-barely-tolerated"
>>    candidate.
>
> Why not just go all the way down?

Who says they wouldn't?  Most voters would equal rank the remaining
candidates anyway.  But consider (a) the Later-no-harm violation, and
(b) time required to rank 150 candidates [extreme CA governor recall
case].

>
>>    Put your approval cutoff just below the candidate with the best
>>    shot at winning.  (I think this is Forest's Approval voting
>>    criterion).
>> Here, that means that the A voters cutoff below A.
>> B voters, realizing this is the strategy, will add a lower
>> preference
>> for A.
>> C voters, if they realize they're in the minority, might then decide
>> to rank their preferred opposition alternative below the cutoff.  If
>> they despise A, they might actually vote for B in sufficient numbers
>> to turn the election around.
>> But you don't get this effect if you remove the approval cutoff.
>> 
>>>Those schemes might or might not be acceptable. I realize they seem
>>>very simple to you, but I think they may still be too complicated
>>>for major public elections. Also, I don't like the idea of requiring
>>>the voter to actually write a number. That's asking for trouble
>>>because the written number will sometimes be ambiguous.
>> I find writing a number to be much faster than filling in an optical
>> cell!
>
> I don't think optical cells are the answer either. What you want is
> a nice, simple touch-screen (or mouse based) system. And yes, of
> course you need to generate paper ballots too.

Absentee ballots?

>
>> 
>>>I envision something like the Graphical Voter Interface (GVI
>>>http://ElectionMethods.org/GVI.htm) that I developed a while back
>> Can't see the screenshots:
>>   Permission Denied
>>   The area you are trying to access has been closed off by the
>> server
>>   administrator.
>
> OK, I fixed it. Take a look at it.
>
>> 
>>>just for kicks. It has a column of buttons, each about a half inch
>>>high by 3 inches wide, with a candidate's name and party on each
>>>one. You select them in order of preference by simply touching them
>>>on a touchscreen (or clicking on them with a mouse on a conventional
>>>monitor). You can always backtrack, of course. You can specify equal
>>>rankings by touching a selected candidate a second time (GVI doesn't
>>>currently allow that, but it could be added).
>> Woowee.  Screen takeover.  Watch those colors and fonts!
>
> I don't understand what you mean by "Screen takeover."

Well, on my computer it is a full screen application with loud colors
;-).

>
>> I'm not sure I find that more intuitive.
>> Anyway, I favor paper ballot counting, period.  Machines would be
>> used
>> only for assistance.  What does your software do then?
>
> Yes, GVI can print paper ballots. However, this feature is just a 
> prototype. it just prints the ballot to a conventional printer.
>

-- 
araucaria dot araucana at gmail dot com