When should iterations end? (fwd)]

[Mike Ossipoff]

Mike Ossipoff writes:
> From dfb Fri Aug 23 02:23:48 1996

[I sent this by the "reply" option, during the time when EM was
sending replies only to the author, not to the whole list. And
so this reply only went to Steve. I thought I'd re-sent it to EM,
but it hasn't posted, so maybe I didn't. So I'm doing so now. Excuse
the extra header below. The message is right after that]


> Subject: Re: When should iterations end?
> To: Steve Eppley <seppley at alumni.caltech.edu>
> Date: Fri, 23 Aug 96 2:23:47 PDT
> From: Mike Ossipoff <dfb at bbs.cruzio.com>
> Cc: dfb at bbs.cruzio.com
> In-Reply-To: <199608211653.JAA15982 at alumni.caltech.edu>; from "Steve Eppley" at Aug 21, 96 9:57 am
> X-Mailer: ELM [version 2.3 PL0]
> Message-ID:  <9608230223.aa10162 at cruzio.com>
> 
> In IR-1, my reason for stopping the count when 1 or more alternatives
> occupy or share highest position in half of the rankings is because
> I consider a majority to be a compelling thing. 
> 
> If we were to express it in terms of votes, so that you're giving
> 1 whole vote to each alternative occupying or sharing highest
> position in your ranknig, at any particular time in the count,
> and if we were to say that we won't stop the count till some
> alternative has a majority of votes cast, that seems to be
> not in the spirit of majoritarianism, and it seems an unreasonably
> high requirement for winning by majority. It's a majority of the
> _people_ that counts.
> 
> Quite aside from that, there's another reason: I don't consider
> Instant Runoff's elimination to be a good thing, and so it seems
> undesirable to continue it any longer than necessary. But the
> 1st reason, in the previous paragraph, is the compelling one.
> 
> ***
> 
> As for Iterative Condorcet, no one gives 1st choice status to
> their next choice unless nothing they've ranked higher has a 
> win. But if a set of alternatives all are now included as 1st
> choices by a majority, then they beat everything else, and 
> one of them has a win. So 1st choice promotions resulting from
> the iterations won't take away their win, since the people who
> have them as 1st choices won't promote their next choices to
> 1st place, since something they like better has a win already.
> 
> It's still possible, it seems to me, that some thingss that you
> like less could also have that honor too, even though you
> aren't part of the majority ranking them 1st. 
> 
> So it might be that none of your current 1st choices has a
> win so far, and the rules would have your ballot extend 1st
> choice status to your next choice (if you've chosen to extend
> the use of that option that far down your ranking).
> 
> But, as in the situation that I discussed before, that only
> happens if something that you like even less than that next
> choice is currently the winner. Under those conditions, don't
> you want to give 1st choice status to your next choice?
> 
> So it doesn't seem to me that Iterative Condorcet needs a
> rule to stop the iterations, other than stopoing them when
> every ballot has given 1st choice status to every 
> alternative that it lists higher than the one currently
> the winner, and that it opts to extend the use of that option
> down to. In other words, I feel that Iterative Condorcet
> doesn't need a special rule to stop the iterations before
> they naturally stop under the basic rules of Iterative
> Condorcet that Steve initially specified.
> 
> ***
> 
> Sure, it's possible, under some conditions, for you to promote
> a next choice to 1st place status, in Interative Condorcet,
> when something you like better would otherwise later aquire a
> win, but for cheaters to contrive that complicated situation
> would be too much to ask of even the most sophisticated cheaters,
> it seems to me. And, without cheating, how is something going
> to have a win in Condorcet if some set of alternatives are
> ranked over it by a majority, as would be the case if the members
> of that set were now 1st choices of a majority? Only if there's
> such a chaotic natural circular tie that everything has a
> majority against it.
> 
> Well maybe that next choice of yours is one of the alternatives
> that's now 1st choice of a majority, but in that case a rule
> to drop alternatives without that honor isn't going to protect
> you from giving away the election to it--under the highly
> contrived conditions under which that can happen.
> 
> ***
> 
> But, it does seem that Iterative Plurlity could use a rule
> to drop from the election any alternatives other than the
> ones that occupy highest position in at least half of the
> rankings. As in IR-1.
> 
> ***
> 
> In fact there's another enhancement that could be very helpful
> in Iterative Plurality: Cancelable votes. So the method would
> be "Cancelable Iterative Plurality":
> 
> If your ballot has given a vote to candidate Z, and it later
> turns out that a candidate higher in your ranking would win
> had you & others not extended their approval set down to
> that candidate, then your ballot takes back the vote it
> gave to that alternative. Why not? Isn't that what you'd
> want to do?
> 
> Of course votes that can't be used against anyone you've ranked
> higher is what you have in pairwise methods. Cancelable Iterative
> Plurality tries for that in a non-pairwise method.
> 
> But, in Cancelable Iterative Plurality, if the cancelation rule
> results in an endlessly repeating cycle of votes given & taken
> back, then the rule should be that the ballots involved in that
> repetition cycle shall cancel the votes in question & leave them
> cancelled.
> 
> Obviously this endless repetition rule adds to the length &
> complexity of Cancelable Iterative Condorcet. That, and the
> cancelation rule itself, seem to make Cancelable Iterative
> Plurality perhaps too complicated to be a practical public
> proposal. Better to just propose Condorcet or Smith//Condorcet,
> it seems.
> 
> But then, if Iterative Plurality, without the cancellation rule,
> were adopted (having been proposed due to Plurality's familiarity),
> then later, the cancellation rule could be added at any time,
> especially when events suggested a need for it.
> 
> ***
> 
> Though the cancellation rule would be much less needed in
> Iterative Condorcet, due to the improbable conditions,
> depending either on impossibly sophisticated cheating,
> or a hopelessly chaotic situation (& other improbable conditions),
> under which that method could have a problem,
> 
> it would still be possible to add a cancellation rule to
> Iterative Condorcet. It might be helpful under those rare
> conditions, but I don't know if that small benefit would
> justify the added complexity of adding that new rule. Ideally,
> if public accptance were no issue, and the goal were just
> to devise the best-working version of Iterative Condorcet,
> the cancellation rule might be desirable, though not
> necessary.
> 
> ***
> 
> Mike
> 
> 
> 
> 
> 
> 
> 
> 
> 
> -- 
> .-
> 


--