[EM] RCIPE version 2

[Richard, the VoteFair guy]

On 7/28/2021 1:08 PM, Kristofer Munsterhjelm wrote:
 > On 27.07.2021 00:16, Richard, the VoteFair guy wrote:
 >> On 7/26/2021 6:20 AM, Kristofer Munsterhjelm wrote:
 >>> ...
 >>> ... Is that right? ...
 >>
 >> Your calculations are correct.
 >
 > Then that's just Borda. Congrats, you've reinvented Borda-elimination :-)


The fact that you believe the RCIPE version 2 method is "borda 
elimination" tells me:

* Other people will make the same mistake of associating the method with 
the Borda count method, which deserves its poor reputation.

* The similarity would be used to attack the RCIPE (v2) method.

So, I'm choosing to abandon creating a version 2, and stick with RCIPE 
version 1.

So, RCIPE continues to refer to IRV with the addition of a "safety net" 
that eliminates Condorcet losers when they occur.  That's less likely to 
be confusing about what the method is.

Your opinion that RCIPE version 2 is borda elimination is supported by 
the following opening sentence in the Wikipedia article titled "Borda 
count":

"The Borda count is a family of positional voting rules which gives each 
candidate, for each ballot, a number of points corresponding to the 
number of candidates ranked lower."

Yet the words "positional voting" link to an article that clearly states 
that the points are determined by the candidate's ranking.

And every example in the Borda count article uses a candidate's ranking 
position.  None of the examples counts how many other candidates are 
ranked below the candidate.

It's true that "a number of points corresponding to the number of 
candidates ranked lower" can be equal to the point count associated with 
the ranking level.  However that equivalence requires that every voter 
is forced to rank every candidate at a different (unique) ranking level.

Interestingly I see that Baldwin's method is "borda elimination."  Correct?

I had expected that RCIPE version 2 was likely to be a method that had 
already been invented.  It's so simple, and yet it yields very good results.

So if anyone knows about a method, besides Instant Pairwise Elimination 
(IPE), that is similar to what I was calling RCIPE version 2, I'd still 
be interested in knowing about that similarity.

Now I'll switch back to creating an animation of RCIPE (version 1). 
Fortunately in the process of imagining ways to animate version 2 I've 
thought of improved ways to animate version 1.

If I have time I may also animate IPE, which does use the code that 
manipulates up arrows with candidate initials on them.

And ideally I'd like to animate the counting done using the 
Condorcet-Kemeny method.  (It would show that swapping the 
sequence/order moves larger numbers of up arrows into the upper right 
triangular area, while the cells with smaller numbers of up arrows move 
into the lower left triangular area.)

One final interesting point is that my favorite single-winner method, 
the Condorcet-Kemeny method, yields the same popularity sequence as the 
Borda count IF every voter can be forced to rank each candidate at a 
unique ranking level (and there are no unmarked ranking levels).  If I'm 
mistaken about this, please let me know.

Once again, thank you Kristofer for your valuable feedback!!!

Richard Fobes


On 7/28/2021 1:08 PM, Kristofer Munsterhjelm wrote:
> On 27.07.2021 00:16, Richard, the VoteFair guy wrote:
>> On 7/26/2021 6:20 AM, Kristofer Munsterhjelm wrote:
>>> ...
>>> ... Is that right? ...
>>
>> Your calculations are correct.
>
> Then that's just Borda. Congrats, you've reinvented Borda-elimination :-)
>
> Well, it's not quite Borda-elimination since the early elimination of a
> Condorcet loser may reshuffle the order of later eliminations, and due
> to the same effect that causes nonmonotonicity in elimination methods,
> lead someone else to win.
>
> But ordinary Borda-elimination does eventually remove every Condorcet
> loser, so it should have little effect on your criterion compliances.
>
> In particular, although if I were selfish I shouldn't point this out,
> Borda-elimination passes Condorcet and the Condorcet loser elimination
> stage doesn't change that. Since your simulator says that it doesn't
> pass Condorcet, I would view its other results with some suspicion,
> particularly given how it's also been wrong about clone independence.
>
> But, since your method is pretty close to Borda elimination, and Borda
> elimination also eliminates Condorcet losers as a matter of course[1],
> you could simplify it (if you want to retain its Borda-elimination
> nature) into this:
>
> 1. Determine the candidate with the fewest arrows, and eliminate that
> candidate. Break ties by IRV (and further ties by Ext-Minmax).
> 2. Repeat from 1 until a single candidate remains. That candidate is the
> winner.
>
> Even if you don't want to, you could run tests comparing this simplified
> version to the one with Condorcet loser elimination - though as
> mentioned, I wouldn't be too confident of the results.
>
> As for Condorcet winner, what I was objecting to (besides me being a
> Condorcetist and preferring Condorcet) is that there doesn't seem to be
> a principled approach to your methods' violation of CW. You used a
> bicycle metaphor: but the attempt to deliberately avoid Condorcet winner
> seems like removing the chain (and subsequently creating a
> penny-farthing) just so that you can say that it's not a bicycle,
> because the pedestrian organization (FairVote) dislikes bicycles.
>
> If you're deliberately setting out to not make a bicycle because
> bicycles aren't liked, you should create something that's consistently
> not a bicycle: that gets some kind of return for not being a bicycle,
> and then has more of a justification of what a good winner is than "this
> isn't Condorcet, but you can see Condorcet from here".
>
> Consider something like a method that explicitly eliminates the
> Condorcet loser, and where the base method otherwise does not pass
> Condorcet. Then the elimination method will pass Condorcet when there's
> an unambiguous order of losers (X is the loser, Y beats only X, Z beats
> only Y and X, etc.). The iterated Condorcet losers provide a
> straightforward order of candidates from most relevant to least
> relevant. But now introduce a cycle somewhere "downstream" of the
> winner. Then by introduction of such a cycle, the Condorcet winner may
> be eliminated early (depending on how the method is constructed). It's
> difficult to see why that should make a difference; I'd say you'd need
> some kind of explicit reason for why something that appears irrelevant
> (the relation between people who would otherwise be losers) matters.
>
> In any case, I don't think FairVote itself would support your method as
> long as it's not IRV. They're first and foremost an advocacy
> organization focused laser-like on IRV and STV, and as your method isn't
> it, they probably won't support it. But even being generous that their
> "Core Support criterion" isn't just a fig leaf (see my post to Forest),
> any method that is Condorcet in the "straight line scenario" above must
> by necessity fail that criterion.
>
> Now, don't get me wrong: I don't think passing Core Support would win
> them over - because again, their thing is IRV. I'm more just
> re-emphasizing that a method that fails Condorcet should have some
> reason for doing so. (E.g. you can get very close to Condorcet while
> still passing the favorite betrayal condition - then passing the FBC
> becomes the reason.)
>
> -km
>
> [1] For that matter, every sequential elimination method that respects
> majority rule will also pass Condorcet Loser, because in the worst case
> that the Condorcet loser remains until the final round, the other
> candidate will by definition beat the loser in the final round.
>