Re: [rtcweb] Voting method choice (Re: Proposed Video Selection Process)

"Parthasarathi R" <partha@parthasarathi.co.in> Sun, 24 November 2013 19:14 UTC

Return-Path: <partha@parthasarathi.co.in>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E3141AE3DE for <rtcweb@ietfa.amsl.com>; Sun, 24 Nov 2013 11:14:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.803
X-Spam-Level: *
X-Spam-Status: No, score=1.803 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 91hN6wtr8J29 for <rtcweb@ietfa.amsl.com>; Sun, 24 Nov 2013 11:14:03 -0800 (PST)
Received: from smtp.mailhostbox.com (outbound-us2.mailhostbox.com [69.93.141.233]) by ietfa.amsl.com (Postfix) with ESMTP id 853081AE1E4 for <rtcweb@ietf.org>; Sun, 24 Nov 2013 11:14:03 -0800 (PST)
Received: from userPC (unknown [122.179.42.105]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id 51CCB63900B; Sun, 24 Nov 2013 19:13:52 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1385320435; bh=RjnIF98IT01qROIt634JBuzec7iqaYv59P88Mf9EE2c=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=ll35kp5SuoXlp3H0adXd8rJQKA/L97nSzwPIR0g/yNeHwOvqQqWIQB0Xvw8BDdMDE 6Fia9YYZe5X/cd35bV6jqzcwOEjy5yiR5h+rmDJFufqkODi3PmVidJOY/AjuASpgCq IXI2ARaDTZk5i2SnRyd5cZr2reQbOxQOjVf1AvKo=
From: "Parthasarathi R" <partha@parthasarathi.co.in>
To: "'Harald Alvestrand'" <harald@alvestrand.no>, <rtcweb@ietf.org>
References: <528E39F4.4010706@ericsson.com> <528E5AF7.5080403@alvestrand.no> <52922ED3.7070908@alvestrand.no>
In-Reply-To: <52922ED3.7070908@alvestrand.no>
Date: Mon, 25 Nov 2013 00:43:50 +0530
Message-ID: <002d01cee949$51a4c3c0$f4ee4b40$@co.in>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac7pNarl0lwzuXaFTfmrWqEuKd8p9QACLErA
Content-Language: en-us
X-CTCH-RefID: str=0001.0A020208.52924FF3.00EA, ss=1, re=0.100, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0
X-CTCH-VOD: Unknown
X-CTCH-Spam: Unknown
X-CTCH-Score: 0.100
X-CTCH-Rules: SUBJECT_NEEDS_ENCODING,
X-CTCH-Flags: 0
X-CTCH-ScoreCust: 0.000
X-CTCH-SenderID: partha@parthasarathi.co.in
X-CTCH-SenderID-TotalMessages: 1
X-CTCH-SenderID-TotalSpam: 0
X-CTCH-SenderID-TotalSuspected: 0
X-CTCH-SenderID-TotalBulk: 0
X-CTCH-SenderID-TotalConfirmed: 0
X-CTCH-SenderID-TotalRecipients: 0
X-CTCH-SenderID-TotalVirus: 0
X-CTCH-SenderID-BlueWhiteFlag: 0
X-Scanned-By: MIMEDefang 2.72 on 70.87.28.142
Subject: Re: [rtcweb] Voting method choice (Re: Proposed Video Selection Process)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 24 Nov 2013 19:14:05 -0000

Hi Harald & all,

IMO, The fundamental problem with these methods (Condorcet & IRV) is that
they are designed to find the winner out of the discrete candidates (A, B,
C) in mind whereas the candidates in this voting is of combination of
discrete and set nature (A, B, (A & B), (A | B)). I like to see the proof
whether the above methods (Condorcet & IRV) are really designed to bring the
correct winner in these set of candidates as well.

I can show how your example of Condorcet fail with (A|B) is as follows: The
candidates are A,B, (A|B) 

A: Codec A
B: Codec B
A|B: At least one of Codec A and B 

If the distribution is like this:

A proponents (40%): A A|B 
B proponents (40%): B A|B 
Compromisers group 1 (5%): A|B A 
Compromisers group 2 (15%): A|B B 

Then under IRV, the first round will go 40/40/20, alternative A|B will be
eliminated, and B will be chosen with 55 as A has 45 only in the second
round.
 
Under Condorcet, the outcomes will be:

- A outranks B on 55%
- B outranks A on 45%
- A|B outranks A on 60%
- A|B outranks B on 60%

Therefore, A|B is a Condorcet winner and election is successful. In reality,
the original winner is B and compromisers group 2 which is interested only
in implementing B which has 55% supporter. Also, A and Compromisers group 1
is interested only in implementing A which is 45%. So, Condorcet winner is
not required to be correct in case A|B, A&B candidates exists in the
election.

Having said that, I agree with you that IVR is also not required to yield
correct election result in case A&B, A|B candidates exists. 

As of now as I mentioned in
http://www.ietf.org/mail-archive/web/rtcweb/current/msg10113.html, the
election result may leads to the situation of "the operation was a success
but the patient died". Please let me know your opinion on the same.

Thanks
Partha

> -----Original Message-----
> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald
> Alvestrand
> Sent: Sunday, November 24, 2013 10:23 PM
> To: rtcweb@ietf.org
> Subject: Re: [rtcweb] Voting method choice (Re: Proposed Video
> Selection Process)
> 
> On 11/21/2013 08:11 PM, Harald Alvestrand wrote:
> > Forking this thread, and leaving aside all consideration of whether
> > the IETF should do voting, whether the electorate is the right
> > electorate for the decision and so on:
> >
> > I wonder if Instant Runoff is the right choice for this situation.
> > Instant Runoff means that when you don't get a majority for anything,
> > you drop the lowest-ranked candidate and distribute the ballots that
> > had this as their #1 across the other candidates.
> >
> > This has the property that in a polarized situation, compromises may
> > get dropped out of the running before the alternatives that they
> might
> > serve as a compromise between.
> >
> > In this case, I'd favour a Condorcet-compatible method, such as
> > Schulze; it provides the guarantee that if a choice is preferred by a
> > majority of the participants over every other choice, it will always
> > be chosen.
> >
> > http://en.wikipedia.org/wiki/Condorcet_method#Schulze_method
> 
> I haven't seen much response to this - except pointing out that no
> voting method is perfect - but I really think the issue of Condorcet vs
> IRV matters in this case.
> 
> We have two strong camps who have a clear preferred choice, and we have
> some possible compromises. Me being the compromising type, I think we
> might be better off with a compromise than one of the strong camps'
> preferences.
> 
> Let's imagine, for a moment, that the options are:
> 
> A: Codec A
> B: Codec B
> C: At least one of Codec A and B
> 
> If the distribution is like this:
> 
> A proponents (40%): A C B
> B proponents (40%): B C A
> Compromisers group 1 (5%): C A B
> Compromisers group 2 (15%): C B A
> 
> Then under IRV, the first round will go 40/40/20, alternative C will be
> eliminated, and B will be chosen.
> Under Condorcet, the outcomes will be:
> 
> - A outranks B on 55%
> - C outranks A on 60%
> - C outranks B on 60%
> 
> Therefore, C is a Condorcet winner.
> 
> IRV is less likely to lead to a second-ranked compromise that everyone
> can live with than Condorcet.
> 
> 
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb