[EM] Trying to have CD, protect strong top-set, and protect middle candidates too

Sun Nov 20 18:38:33 PST 2016

Hi Kevin--

On Sun, Nov 20, 2016 at 6:57 PM, Kevin Venzke <stepjak at yahoo.fr> wrote:

>
>
> IC-Smith//MMPO shouldn't work for FBC, but "IC,MMPO" should work (i.e.
> find the Condorcet winners as under the ICA method, but instead of picking
> the winner with approval, use the original max defeats, without eliminating
> anyone).
>

Its advantage over MMPO(pt/2), then, would be that it meets the IC form of
the Condorcet Criterion.

>
> I'm currently working on a new method DNA scheme, where a code is
> generated to represent a method, based on who it elects in a specific
> selection of 3-candidate, 3-faction scenarios.
>

But surely a lot of problems require more than 3 candidates. For example,
MMPO & MDDTR have their burial-vulnerability problems only with at least 4
candidates.

Yes, CD needs work. But, in the meantime, we know when a method has or
doesn't have a chicken-dilemma problem. MDDA(pt/2) doesn't have one,and
that's the main thing.

So yes, I can't defend the current form of CD.

But would I be able to revise it? I tried to revise my vote in the ongoing
Electowiki poll on voting systems (by 0-10 Score), but when I tried, I got
a message that said that access isn't available. Is that poll just closed,
or is it a systemwide problem?

I don't think that anyone should be able to revise, modify or delete what
someone else has posted to Electowiki. But the original poster should be
able to revise his or her work there.

And that poll ongoing Electowiki voting-systems poll should remain open.

I can understand why it uses Score, because there's so little agreement on
which rank-count is best. Also, Score is more easily-counted, its count is
more easily programmed. Then shouldn't that poll do a running
count-calculation, displaying the Score totals, & the winner?

[Replying farther down] :

>
> Related to this, one issue I'd like your thoughts on is how CD is defined
> on the wiki: Chicken Dilemma Criterion - Electowiki
> <http://wiki.electorama.com/wiki/Chicken_Dilemma_Criterion>
>
> Chicken Dilemma Criterion - Electowiki
> <http://wiki.electorama.com/wiki/Chicken_Dilemma_Criterion>
>
>
> Premise item 4 used to say "Voting is sincere, except that the B voters
> refuse to vote A over anyone."
>
> But now it says "The A voters vote B over C. The B voters refuse to vote
> A over anyone."
>
> So now it appears that CD might apply even when the B faction votes B>C
>

Yes, by the strict wording, it does. I've since defined, on EM, a "Weak CD"
that's more like what I initially intended with CD. Some methods meet both.

The CD definition needs revision.

[Replying farther down] :

> :
> 5 C
> 4 A>B
> 3 B>C
>
> That creates an issue, because MMPO elects B in this scenario. So I'm
> thinking the wiki needs an edit.
>
> I also wonder about creating a stronger version of CD, whose penalty can
> be invoked not just by the B faction, but also by the A faction. I think
> there are probably a few reasonable methods that would satisfy this.
>

I'd be interested in it, though of course my intention has been to protect
the larger faction of the majority pair of factions.

>
> Kevin
>
>
> ------------------------------
> *De :* Michael Ossipoff <email9648742 at gmail.com>
> *À :* Forest Simmons <fsimmons at pcc.edu>
> *Cc :* EM <election-methods at lists.electorama.com>
> *Envoyé le :* Dimanche 20 novembre 2016 16h10
> *Objet :* Re: [EM] Trying to have CD, protect strong top-set, and protect
> middle candidates too
>
> I've unsuccessfully looked for an exception to this statement of mine:
>
> "It's probably impossible in principle, with any possible method, to both
> protect from chicken-defection by a candidate's voters, and also give hir
> full truncation & burial protection."
>
> Here's what I tried:
>
> I know of 3 ways of avoiding chicken-dilemma:
>
> 1. IRV does it by not sharing any votes unless your top-ranked candidate
> is eliminated.
>
> 2. MDDA(p/2) does it by the A voters denying an approval to B, in the
> chicken-dilemma example.
>
> 3. MMPO does it by the fact that, with C voters treating A & B equally, B
> can't do better than A,  because the A faction is larger.
>
> It could appear as if #3 is promising, because there's no need for A
> voters to deny support to B.
>
> The trouble is that,  though the A voters don't need to deny support to B,
> the support that they give to _anyone_ is iffy. MMPO doesn't really have
> burial-resistance for _anyone_ you middle-rank. Truncation of the buriers'
> candidate doesn't prevent hir from successfully burying, any more than it
> does in MDDTR.
>
> Well, the best that can be said for MMPO, in regards to burial resistance,
> is that burial isn't quite as easy & safe as it can be in MDDTR.
>
> In MDDTR, the buriers merely need for everyone to be majority-beaten, &
> for their candidate to have a plurality. In MMPO, the buriers need for all
> the other candidates to be _more_ beaten than their candidate. So the
> requirement is a bit harder, making the burial a little less safe &
> dependable.
>
> The pt/2 provision seems to avoid MMPO's "Hitler with 2 votes" bad-example.
>
> So, between MDDA(pt/2) and MMPO(pt/2), it's a choice between fully
> protecting middle-ranked candidates whom you don't deny approval to, vs
> making burial a little harder & less reliable & less safe than in MDDTR
> (but not really resisted), for all of your middle-ranked candidates.
>
> ...Complete protection to all of your middle-ranked to whom you don't deny
> approval, vs some questionable maybe-protection to all of your
> middle-ranked.
>
> MDDA(pt/2) gives the choice to the voter, regarding support vs
> chicken-deterrence, instead of being a crapshoot-compromise like MMPO(pt/2).
>
> -------------------------------------------------
>
> I also considered IC-Smith//MMPO.
>
> Maybe it fails FBC, but I didn't find where it does. It share's MMPO's (&
> MDDTR's) usual lack of real anti-burial support for any of your
> middle-ranked candidates.
>
> I guess its advantage over MMPO(pt/2) would be its limitation to the
> IC-Smith set, if that's really achieved without losing FBC.
>
> ---------------------------------------------------
>
> I wanted to mention these possibilities, but I don't regard either of
> these gamble-support methods as a rival to MDDA(pt/2).
>
> ---------------------------------------------------
>
> Michael Ossipoff
>
>
>
>
>
>
> On Sun, Nov 20, 2016 at 2:42 AM, Michael Ossipoff <email9648742 at gmail.com>
> wrote:
>
> Voting, using this method, I might often want to deny approval to a
> high-ranked candidate (even top?), without denying to the rest of my
> ranking, approval & full protection from burial & truncation.
>
> Maybe I just don't trust to voters of an excellent candidate whom I rank
> high, but I have no reason to not want to protect the rest of my ranking
> from burial or truncation by my unranked candidates' voters.
>
> So I suggest that, in addition to an approval cutoff, a voter should also
> be able to individually deny approval to any individual candidate(s).
>
> It's probably impossible in principle, with any possible method, to both
> protect from chicken-defection by a candidate's voters, and also give hir
> full truncation & burial protection.
>
> Michael Ossipoff
>
> On Fri, Nov 18, 2016 at 6:56 PM, Forest Simmons <fsimmons at pcc.edu> wrote:
>
> Does optional approval cutoff wreck burial protection?
>
> Suppose we have a sincere scenario
>
> 40 C>B
> 35 A>B
> 25 B>C
>
> and the C faction decides to bury the CWs B.  The B faction anticipates
> this and responds by truncating C.  It is in the interest of the A faction
> to leave the default implicit approval cutoff in place.  The C faction
> doesn't want to give A too much support so they use the explicit cutoff
> option:
>
> 40 C>>A
> 35 A>B
> 25 B
>
> The approval winner is B the CWs.
>
> If they left the implicit cutoff in place it would be worse for them;
> their last choice would be elected.
>
> So I think MDDA with optional explicit cutoff is fine with respect to
> truncation and burial.
>
> How about the CD?
>
> In this case the sincere profile is
>
> 40 C
> 35 A>B
> 25 B>A
>
> The B>A faction threatens to defect from the AB coalition.
> The A faction responds by using the explicit cutoff:
>
> 40 C
> 35 A>>B
> 25 B
>
> The approval winner is C, so the threatened defection back-fires.
>
> It seems to me like that is plenty of chicken defection insurance.
>
> The obvious equilibrium position (for the chicken scenario) is
>
> 40 C
> 35 A>>B
> 25 B>>A
>
> Under MDDA(pt/2) the only uneliminated candidate is A.
>
> But if the B faction defects, all candidates are eliminated, and the
> approval winner C is elected.
>
> This is why I like MDDA(pt/2).
>
> An interesting fact is that MDDA(pt/2) is just another formulation of my
> version of ICA.  They are precisely equivalent.  Here's why:
>
> In my version of ICA, X beats Y iff
>
> [X>Y] > [Y>X] + [X=Y=T] + [X=Y=between] , in other words,
>
> [X>Y] > [Y:>=X] - [X=Y=Bottom],
>
> which in turn equals
>
> 100% - [X>Y] - [X=Y=Bottom], since  100%= [X>Y] + [Y>=X].
>
> So X beats Y iff
>
> [X>Y] > 100% - [X>Y] - [X=Y=Bottom].
>
> If you add [X.Y] to both sides and divide by 2, you get
>
> [X>Y] +[X=Y=Bottom]/2 > 50%,
>
> precisely the "majority-with- half-power-truncation" rule.
>
> So (my version of) ICA is precisely equivalent to MDDA(pt/2).
>
> I believe it to be completely adequate for defending against burial,
> truncation, and Chicken Defection.
>
>
> Now suppose that p<q<r, and p+q+r=100%, and we have three factions of
> respective sizes p, q, and r:, with r + q > 50%.
>
> p: C
> q: A>>B
> r: B>>A
>
> Then under the pt/2 rule both C and B are eliminated, but not A, so A is
> elected.
>
> Suppose that the B factions defects.
>
> Then A is also eliminated, and the approval winner C is elected.
>
> Etc.
>
> So which of the two equivalent formulations is easier to sell?  ICA or
> MDDA(pt/2) ?
>
> Forest
>
>
>
>
> ----
> Election-Methods mailing list - see http://electorama.com/em for list info
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.electorama.com/pipermail/election-methods-electorama.com/attachments/20161120/ce5df110/attachment-0001.htm>