[EM] Jameson: SODA & FBC

MIKE OSSIPOFF nkklrp at hotmail.com
Wed Feb 29 14:23:36 PST 2012


You wrote:

Still, again I have to ask you, Mike: where's SODA? 
You were right earlier that SODA fails FBC. But there are three 
mitigating factors.
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.

You continued:

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.

You continued:

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.

You continued:

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.

You continued:

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"?

You continued:

 (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.

You continued:

, 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.)

Mike Ossipoff

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.electorama.com/pipermail/election-methods-electorama.com/attachments/20120229/b529915a/attachment-0003.htm>

More information about the Election-Methods mailing list