On Fri, Dec 06, 2002 at 06:02:12PM +0100, Matthias Urlichs wrote: > Frankly, I don't think that special treatment of the default option > is a good idea. We are already using supermajority rules, which gives the > default option extra weight. Why would we want _another_ rule which does > basically the same, but somewhat differently? Yes, we do. The rules aren't separate, they're two parts of the same thing that're used to get the desired result. The result is what's been pulled out of a hat, not the rules. The result, if you'll recall, is that: for an option with a supermajority of N:1, then 1/(N+1) of all the votes voters should be able to easily and reliably block any given option from winning. > Anyway, if you don't eliminate defeats by the default option, then the > default option is always the winner(*) if it's in the Schwartz set. Yes. > (*): unless there's a tie, probably. Which Raul gave an example of. > > Likewise: you already eliminated A because it didn't satisfy its > > supermajority requirement against the default option. > There was no supermajority requirement stated in that example. Ah. You can do the same thing with Raul's rule, roughly: "if A is an option with a supermajority requirement (N:1), and in a scaled comparison, it's defeated by the default option (V(A,D) / N < V(D,A)), then that defeat is never the weakest (but defeats between the default option and options that don't have a supermajority requirement are treated normally)" Personally, I'd rather treat non-supermajority options in the same manner as a "1:1" supermajority option would be treated. > The basic CpSSD algorithm has a few rather nice properties. IMHO it is in > no way certain that any of the proposed rules which change this basic > algorithm do not destabilize it and allow for insincere/strategic voting, > or yield a surprising result which the voters will not accept. Personally, I think you're overanalysing. You're going to get some unstable situations with surprising results where insincere voting can be beneficial no matter what system you decide on: that's what Arrow's Theorem tells you. Adding supermajority limitations will give you more surprising results: that's what happens when you have contradictory axioms to start with, then add in another one. > We thus should implement a supermajority-capable algorithm which doesn't > break CpSSD. That's a non-sensical statement. By definition a "supermajority-capable algorithm" will give different results to CpSSD in different cases. It *won't work the same*. It'll also be more biassed to do-nothing outcomes. It'll also allow minorities to strategically block certain outcomes. _That's the point_. > As I see it, the only method which can do that, by virtue of > not touching the basic CpSSD algorithm, is to eliminate a candidate option > from the ballot and re-run the voting algorithm from the top if the winner > doesn't have a sufficient supermajority against the default option. Rerunning Condorcet algorithms tends to result in strange inconsistencies which I can't recite off the top of my head. Maybe Raul can refer you to some of the discussions we had off list last year about this, or perhaps you can do a search through some of the stuff Manoj has posted. I think it's time to stop going round in circles on this topic and vote on it. Cheers, aj -- Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/> I don't speak for anyone save myself. GPG signed mail preferred. ``If you don't do it now, you'll be one year older when you do.''
Attachment:
pgprzHehXz8DP.pgp
Description: PGP signature