[EM] Jameson: SODA & FBC
nkklrp at hotmail.com
Wed Feb 29 14:23:36 PST 2012
Still, again I have to ask you, Mike: where's SODA?
You were right earlier that SODA fails FBC. But there are three
1) Failure would be very rare; I hope to be able to be more precise about this in the near future.
I told you why that doesn't help. You can't assure a voter that SODA can't make them regret that they didn't vote someone else over their favorite. If you can't give that
assurance, then voters will continue to favorite-bury.
2) Even when failure happens, SODA would never fail
FBC without at least giving the non-betrayed favorite a chance to
restore FBC by giving the win to the should-have-betrayed-for-them lower
choice. (This is not mathematically necessary, but to make it untrue,
you must divide the candidates in question into several clones, or give
them a negligible fraction of their votes in delegated form, either of
which makes an already-strained scenario completely implausible.)
You'd have to give more detail. The above paragraph isn't specific enough.
3) There is a polytime(?), summable fix for the
method, which restores full FBC; though I admit it's an ugly hack.
Basically, there's a way to use the co-approval matrix to check if FBC
has been violated and make those voters for whom it was violated
"virtually" betray their favorite. Since, when that happens, it is the
only way to give these voters a winner who they approved, it is not
hurting them at all. There's also a slightly less-ugly, but imperfect,
fix that merely makes the process in step 2 automatic; this would be
good enough in practice.
Again, something more specific would be necessary.
But, just from what you said, I suggest that the automated virtual favorite-betrayal that you suggested would
change the method to an entirely different method, bringing with it a new set of problems. For those problems to show, so that their seriousness can
be discussed, the suggestion in your above paragraph would have to be spelled out specifically, in detail.
I believe that with these three factors, and most
particularly the first one, SODA's FBC failure is tolerable.
As I said yesterday, even IRV's FBC failure would be tolerable, if voters weren't so resignedly over-compromising.
An FBC failure can't be tolerable, because it means that you can't assure voters that it's safe to vote their favorite
in 1st place. As I said, for the excessively timid, giveaway-resigned, over-compromising voter, "probably" won't do.
And as for cooperation/defection: SODA without
question solves that problem more completely than any of the alphabet
soup you mention.
Nonsense. Methods and criteria are routinely designated by letter-abbreviations. You mean alphabet soup like "SODA"?
(Though I'd still really appreciate it if you made
quick electowiki pages for all of that
I definitely intend to, within the next few days.
, because I'd bet that nobody but
you actually knows what every one of those means ,and it would be
considerate of you not to ask us to continually look up all the
definitions and redefinitions in the archives).
Again, nonsense. You were reading the mailing list at the times when I defined each and every method and criterion that you're referring to. Most were initially defined in posts
that named them in the subject line. All of the new method and criterion definitions of mine were posted during a period of a few months, from October or November to the present.
Yes, new definitions should always be posted to the electowiki too. --even though a search at the archives page will quickly find recent references to
a method or criterion name.
So yes, I will definitely post the new definitions to the electowiki.
By the way, how many times have I asked for the definition of IRV3/AV3? It's not at the electowiki either. The definition didn't come up in archives
searches. Dave repeatedly refused to post its definition.
Alright, a few of my new method definitions weren't posted with a subject line that named them, so I'll repeat here something I've several times posted:
MMT and GMAT are defined at postings that name them in the subject line.
MTAOC was defined in a posting that named it in the subject line. That posting consisted of pseudocode for an algorithm for determining which middle ratings are
to be kept and which are discarded due to lack of mutuality, and for thereby re-calculating the candidates' numbers of middle ratings.
As I've said several times:
MCAOC is identical to MTAOC, except that the method is MCA instead of MTA.
AOC is Approval, in which optional conditionality-by-mutuality is implemented as shown in the MTAOC pseudocode.
AOCBucklin is ABucklin in which optional conditionality by mutuality is implemented in that manner.
As I've said before, ABucklin is just a more convenient name for ER-Bucklin, as defined at the electowiki.
In AOCBuckliln, the conditionality-by-mutuality calculation (the one described by the pseudocode) must be done anew for each round of
Bucklin vote-giving. In AOCBucklin, every vote that a ballot has, so far, given to a candidate (other than by 1st ranking) counts as a middle rating,
for the purposes of the pseudocode algorithm.
AC means Approval in which conditionality-by-mutuality is automatic rather than optional. That could just mean that the method is AOC, except that
instead of designating unconditional and conditional approvals, the voter desginates favorites and less-than-favorite approved candidates, for whom
the approvals are counted as conditional.
But MMT and GMAT qualify for the name "AC", because they amount to automatically conditional Approval.
MTAC is MTAOC in which all middle ratings are automatically conditional. MCAC is MCAOC in which all middle ratings are automatically conditional.
ACBucklin is AOCBucklin in which all middle ratings are automatically conditional. (As I said, any vote that a ranking gives to a candidate, other than
at 1st rank, is a "middle-rating" for the purposes of the conditionality-by-mutuality algorithm that I posted.)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Election-Methods