[EM] AFB Ranked Pairs Attempt

[Gustav Thorzen]

On Mon, 20 Apr 2026 19:54:43 +0000 (UTC)
Kevin Venzke <stepjak at yahoo.fr> wrote:

> Hi Gustav,
> 
> Le lundi 20 avril 2026 à 13:00:19 UTC−5, Gustav Thorzen via Election-Methods <election-methods at lists.electorama.com> a écrit :
> > That is quite the counterexample,
> > but mind if I ask why you did not mention the monotonicity failure
> > for the reversed version where we go from C winning to B winning
> > by lowering B?
> 
> I wasn't checking the reversed method, so it wasn't on my mind. From your original
> post I wasn't totally sure whether you thought the reversed method was still
> monotone, but it surely isn't, because it penalizes candidates for getting more
> votes in their losing contests.
> 
> The reversed method of the new suggestion has a similar issue: Being penalized for
> getting more votes when on the winning side.

I initially put these ideas aside thinking just that,
but I got hopefull when I discovered that MB-ISDA
was obtainable independently of locking order,
since that threw out a conjecture I used in an attempt to
disprove Monotonicity. Not that it mattered in the end.
 
> > So at this point I decided to play around with similar versions to the proposed method,
> > since my guess that sorting by greater or equal would be the key.
> > specifically I found replacing the scoring of each entry from
> > v(Winner > Loser) + v(Winner = Loser) to strictly v(Winner > Loser),
> > while keeping sorting largest first to lowest last in place,
> > makes things a little more hopefull
> 
> This territory is a little better explored, but I think four candidates are needed
> for some of the demonstrations.
> 
> The issue is not how you count the defeat strengths, but that the locking mechanism
> permits chaotic effects. I tried to warn about this earlier, but I didn't mention
> locking per se, maybe.
> 
> Favorite betrayal:
> 
> 0.411: C=A>B>D  ->  A>B>C=D  (i.e. C is betrayed)
> 0.377: D>A>C>B
> 0.158: B>D>C>A
> 0.052: A>D>C>B
> 
> Win moves from D to A.
> (First the B>D win is rejected, then D>A is.)

I just noticed the ratios not summing to 1,
since it looks like rounding errors I will assume
this won't affect anything relevant.

First round
0.830 A>B
0.788 C>B
0.587 D>C
0.569 B>D
0.535 D>A
OMB(T2B) winner D
OMB(B2T) winner B

Second round
0.842 A>C
0.830 A>B
0.569 B>C
0.569 B>D
0.535 D>A
0.535 D>C
OMB(T2B) winner A
OMB(B2T) winner A

So the AFB failure applies to both.

> Later-no-harm:
> 
> 0.377: C>A>B>D
> 0.277: D>A>B=C  ->  D>A>C>B  (i.e. add lower preference for C)
> 0.199: A>B>D>C
> 0.145: B>D>C>A
> 
> Win moves from A to C.
> (First the C>A win is rejected, then D>C is.)
> 
> Later-no-help:
> 
> 0.350: B>A>C=D  ->  B>A>D>C  (i.e add lower preference for D)
> 0.331: D>C>B>A
> 0.240: C>A>D>B
> 0.077: A>B=D=C
> 
> Win moves from C to B.
> (First C has no majority losses; then it does, to D, and C places last in the ranking.)
> 
> Again, hopefully no errors.

I did not find any errors,
but I did not check in detail for LN-H* counterexamples
since the AFB failures leaves the methods moot for baseline comparison,
and I am out of Ranked Pair variant ideas with potential.
(Actually there is MMPO locking order, but that have
edge cases I need to figure out definitions to deal with,
before it becomes an actual method.)
In any case MB-ISDA follow trivially from only
considering Majority-Beats and refusing to lock cycles,
regardless of locking order,
in case anyone have other ideas to try.

> A pattern is that which defeats get rejected or locked seems to lack a clear
> connection to how we modified the ballots. This makes it extremely difficult to
> offer guarantees about the effects of vote changes.

I agree on this, I initially made good progress using
conservation laws resulting from only considering Majority-Beats,
but failed to cover some cases (including every equally scored matchups),
not that it would have worked knowing these counterexamples.

> > So thanks for the great conter examples,
> > this will save my much otherwise wasted time and effort.
> 
> I hope I could help, all in all.

Well, until I get decent at finding nontrivial counterexamples on demand,
simply knowing what is and is not compatible makes learning by reverse enginering
theorems and proof a lot easier (let alone time and effort saving on dead ends),
and by extension every attempt to prove something.

Gustav