[EM] No. Condorcet and Hare do not share the same problem with computational complexity and process transparency.

[Closed Limelike Curves]

>
> "Strong monotonicity" is my term for the stronger mono-raise where
> raising A can't change whether the outcome ranks some other B ahead of
> C. Range passes it, for instance, but it's very rare in ranked methods.

Am I misunderstanding this, or is it just independence of irrelevant
alternatives?

On Tue, Mar 26, 2024 at 5:15 PM Kristofer Munsterhjelm <km_elmet at t-online.de>
wrote:

> On 2024-03-26 00:42, Closed Limelike Curves wrote:
> > On Mon, Mar 25, 2024 at 12:39 PM Richard Lung <voting at ukscientists.com
> > <mailto:voting at ukscientists.com>> wrote:
> >> The non-monotonicity of STV just owes to it trailing a remnant of
> >> plurality voting, in its "last past the post" exclusion count.
> >
> >
> > No, the issue is the multi-stage method—the more elimination rounds you
> > have, the more likely you are to have a negative voting weight event.
> > Pretty much every sequential-loser method has the same problem.
>
> Yes, though I think three candidates suffice for weighted positional.
> Say you have a Condorcet cycle, A>B>C>A, and the base method passes
> majority and monotonicity but fails either LIIA or strong monotonicity
> for three candidates. Then it's possible that raising A can lead the
> loser of the first round to go from C to B, e.g. the base method's
> ordering going from something like
>
> B>A>C
>
> to
>
> A>C>B
>
> which, in the context of an elimination method, means that in the
> original election, C is eliminated and then A beats B pairwise; but
> after A is raised, B is eliminated and C beats A pairwise.
>
> "Strong monotonicity" is my term for the stronger mono-raise where
> raising A can't change whether the outcome ranks some other B ahead of
> C. Range passes it, for instance, but it's very rare in ranked methods.
>
> I'm prettty sure you can prove such a strong monotonicity failure for
> every weighted positional method by using linear programming. And
> probably for a bunch of other methods as well.
>
> >> The Surplus transfer election count, especially Meek method, is
> >> monotonic.
> >
> > That's also not correct; see Pukelsheim's book on apportionment for why
> > every quota rule method is nonmonotonic. I do think /most/ of STV's
> > nonmonotonicity comes down to the IRV elimination, though.
>
> To my knowledge, his 2014 book only mentions house size monotonicity and
> vote ratio monotonicity. House monotonicity is compatible with quota.
> (Imagine a method that eliminates the one winner that won't cause a
> quota violation later on, and then continues doing so until the right
> number of seats has been reached.)
>
> Vote-ratio monotonicity seems to be closer to mono-add-top, since
> Pukelsheim talks about a party's weight increasing while another party's
> weight is fixed at unity. I haven't looked into the proof in detail, but
> I suspect the reason that this works is because adding weight changes
> the value of the quota. Plain old mono-raise wouldn't do that, because
> the number of voters doesn't change.
>
> (Here's an interesting thought: Set the elimination order to some
> predetermined order before running STV. Use the same logic: while
> someone has more than a quota, elect him and redistribute surpluses.
> Then eliminate the remaining candidate who's ranked last on the
> predetermined order, and repeat. Is this method monotone? Doing it like
> this would remove the IRV/strong monotonicity failure-related problems
> mentioned above.)
>
> >> I have invented an STV exclusion count which is an iteration of the
> >> election count; both therefore monotonic; a "scientific" one-truth
> >> voting method, unlike other voting methods the world uses. I posted
> >> programmers links, none of which, the list manager has so far redeemed.
>
> I just downloaded the EM archives from
> http://lists.electorama.com/pipermail/election-methods-electorama.com/
> to run a grep through the links and find any software links.
>
> And I think this is it:
>
> https://github.com/Esrot-Clients/STV_CSV/tree/master
>
> referenced in this post:
>
>
> http://lists.electorama.com/pipermail/election-methods-electorama.com/2023-October/004988.html
>
> So it has already been posted :-)
>
> -km
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.electorama.com/pipermail/election-methods-electorama.com/attachments/20240326/e1b8acf2/attachment-0001.htm>