[EM] Current SODA not monotonic; fixable. (mono-voter-raise)
Jameson Quinn
jameson.quinn at gmail.com
Fri Apr 19 11:09:50 PDT 2013
Consider the following scenario in SODA:
1: A(>C>B>D)
2: B,X
2: C(>B>A>D)
1: D(>A>C>B)
1: null
Presume all ties are predictably broken for the alphabetically-first
candidate (without this presumption, you'd need larger numbers, but you
could still make a similar scenario). Under SODA with rational delegation
assignment, C has a choice. If C does not approve B, they are giving A and
D a choice between approving A and C so C wins, or only A so A wins; since
both A and D will choose the latter, this is tantamount to electing A. If C
does approve B, then B will win regardless of what A and D do. C prefers B,
so B wins.
But if the last null voter adds an undelegated approval for B, then if C
approves nobody and D and A approve only A, the result shifts from A to B.
Since C knows that A and D will prefer to give the win to C, now C can
safely not approve B, and win.
So an extra approval for B caused B to lose.
Now, even with this flaw, SODA is still a very good system. I've built
dozens of voting scenarios in my time, and I can't remember ever building
one that took me this much work to get it working the way I wanted. (Note
that among its many carefully-balanced aspects, it includes a Condorcet
cycle C>B>A>C.) I honestly believe this scenario would never arise. For
practical purposes, SODA is indeed monotonic.
Still, the lack of bulletproof monotonicity puts a serious damper on SODA's
criteria compliances. If I had mono-voter-raise, I could prove the rest of
monotonicity, then FBC, a doubly-strong delegated equilibrium for a
majority Condorcet winner (which makes it usually rational to delegate),
and voted Condorcet, and mutual majority, and probably some others. Without
mono-voter-raise, all those proofs fall apart.
So I'm considering fixing SODA. The fix that's necessary is to allow
candidates to commit to forego some of their votes in the final count. In
other words, B here could simply say "we won't count that extra approval".
With this fix, I can prove monotonicity; and, as I said, the situation
would arise once in a purple moon.
So, what do people think? Should I change the default definition of SODA to
make it have better compliances? Or should I keep it the way it is because
the change would never matter in practical terms and would only make the
system sound more complex?
Sincerely,
Jameson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.electorama.com/pipermail/election-methods-electorama.com/attachments/20130419/6c17100c/attachment.htm>
More information about the Election-Methods
mailing list