[EM] Jameson: SODA & FBC

[Jameson Quinn]

2012/2/29 MIKE OSSIPOFF <nkklrp at hotmail.com>

>
> Jameson:
>
> 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.
>
> [endquote]
>
> 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.
>
> Actually, with SODA, it does help, because you can know ex ante (by
looking at the predeclared preferences) when you are safe by FBC. That is,
if you prefer A>B, and B prefers A, or A prefers B, or A and B both prefer
a certain viable C, then you are safe. Only if B prefers the most-viable
third candidate C, but A is indifferent between B and C, then you might
consider a favorite-betraying vote for B. And even then, it's only
appropriate if A very nearly, but not quite, is able to win... not exactly
the situation where favorite betrayal is the first thing on your mind.

This is a specific enough circumstance that favorite-betraying strategy
would never "take off" and become a serious factor in SODA.



>  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.)
>
> [endquote]
>
> 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.
>
> [endquote]
>
> 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.
>
> [endquote]
>
> 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.
>

With SODA, you can give that as a solid ex-ante guarantee to most voters,
just not quite all of them. This is unlike the situation in most voting
systems, where you can make no solid guarantees before the vote unless you
can make them to all voters.


> 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.
>
> [endquote]
>
> Nonsense. Methods and criteria are routinely designated by
> letter-abbreviations. You mean alphabet soup like "SODA"?
>

I wasn't saying that SODA was superior because you used acronyms and I
didn't, I was just using a collective term to refer to your proposals. I'm
sorry if you found it offensive, there was no disparagement intended, and
certainly not on the basis of names.


>
> You continued:
>
>  (Though I'd still really appreciate it if you made quick electowiki pages
> for all of that
>
> [endquote]
>
> 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).
>
> [endquote]
>
> 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.)
>
> Thank you for the definitions. It really is easier when you put them all
in one place like this. Anyone who's looking for these definitions later
can search for "definitions in one place" or "definitions together" and
they'll find this message with the definitions above.

Jameson



> Mike Ossipoff
>
>
>
> ----
> Election-Methods mailing list - see http://electorama.com/em for list info
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.electorama.com/pipermail/election-methods-electorama.com/attachments/20120229/799e9fe4/attachment-0004.htm>