Re: Condorcet Voting and Supermajorities (Re: [CONSTITUTIONAL AMENDMENT] Disambiguation of 4.1.5)
On Tue, Dec 05, 2000 at 12:32:12AM +1000, Anthony Towns wrote: The Condorcet criterion says that if there's a single option that pairwise beats every other option, it should win (assuming there's no supermajority requirement, and quorum is met). That's a relatively weak criterion, all things considered. On Mon, Dec 04, 2000 at 11:35:45PM -0500, Buddha Buck wrote: "All things considered" just being: -- it doesn't deal with supermajorities -- it doesn't deal with quorum issues -- it doesn't state what should happen if there isn't a single option that pairwise beats every other option. I was refering to this last one. It's what the current A.6(2) and A.6(3) are for. (The Condorcet criterion doesn't say anything about the ambiguous cases we've been talking about) I thought we'd agreed that they are to ensure that the Smith criterion is met (which is more specific than the Condorcet criterion). If A.6(3) is supposed to reduce the options to the Smith set, it is very poorly written. I guess this depends on whether you think that Dominates means "pairwise beats" or "transitively beats". I think it means "transitively beats". I do see that other people (you, anthony) disagree with me, and I think that's sufficient reason to consider a constitutional amendment to resolve this issue. [I'd like to achieve agreement on a few other issues, however, before I propose anything formal.] Thanks, -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: Constitutional voting, definition of cummulative prefererence
Raul Miller wrote:
I would like to know if anyone have a specific problem with the following
concept of cumulative preference:
An individual ballot prefers option A to option B, if:
(*) Option A is mentioned at some preference, and option B is not
mentioned at all, or
(*) Option A is mentioned at a lower cannonical preference number than
option B. [For example: 1st is a lower cannonical number than
5th, so a ballot which rated option A as its 1st preference and
option B as its 5th preference would prefer option A to option B.]
This is a clear definition of 'prefers', which is better than the existing
constitutional wording in that it indicates how truncated ballots should be
handled. Clarifying this is a good idea if the constitution is amended, and
your interpretation is the same as the one that Debian is currently using,
based on my analysis of previous voting results. Treating unranked
candidates the same as if they had been ranked equally in last place is also
the assumption we always make on the Election-Methods list. It is always
desireable to assume this meaning with pairwise methods, otherwise a voter
who truncates will not effectively indicate any preference between his
ranked and unranked choices, and this will have unintended results. For
example, it would be generally unreasonable to assume that if someone votes:
ABC
out of five candidates {A,B,C,D,E}
that s/he actually considers E to be as good as A, yet that's how this vote
will be treated if the method doesn't assume the ranked candidates are
preferred to unranked! In other words, interpreting this ballot to mean:
ABC(D=E)
would be sensible; interpreting it as:
ABC, (A=D=E), (B=D=E), (C=D=E)
would not. This would have no effect in a method like STV, but for pairwise
methods it is a critical issue. Fortunately, it appears that Debian has
been handling this correctly all along.
One point though -- I recommend that you avoid reference to numerical
rankings in the constitutional wording. So long as ballots are submitted by
e-mail, it may make sense for voters to number the options. In the future,
however, you might use a web interface or some other technique for ordering
candidates in which the options don't even have visible numbers, but are
ordered graphically, with preferred options at the top, and disliked options
at the bottom. If Debian is saddled with restrictive language that requires
preferences to be numbered, the constitution might need to be changed again
to accommodate the different method(s) of expressing a ranking (or
nitpickers might challenge results, etc.). I think it would be better to
just use general terms like 'ranked higher' and 'ranked lower', and leave
the specifics to an ordinary voters' guide, rather than embed these details
in the constitution.
A set of ballots cumulatively prefers option A to option B if:
* more individual ballots individually prefer option A to option B than
prefer option B to option A, or
* There is an option C, where A is cumulatively preferred to option C,
and option C is cumulatively preferred to option B.
I am not exactly sure why you are defining 'cumulatively preferred' to
indicate transitive majority preference between options, so I can't say for
certain whether or not this is a good idea, because I don't know what you
intend to use it for. However:
1) Almost all pairwise methods deal exclusively with whether one option A is
preferred/beats/defeats/dominates another, but this is a simple option-pair
comparison that does not imply any sort of transitivity. To define most
pairwise methods, it is important to precisely define this simple
relationship and label it; Debian's existing term, 'dominates' is as good as
any.
2) The term 'cumulative' implies an additive rather than transitive
relationship, so it would probably be better to say 'transitively preferred'
rather than cumulatively preferred. Another reason to avoid the term
'cumulative' is that it is frequently used in connection with an inferior
multi-winner voting method called 'cumulative voting', in which each voter
gets an equal parcel of votes (usually 3 or so), and allocates these as they
desire among the candidates (3 on one candidate, 1 each on 3 candidates,
etc.) Using this term in connection with pairwise voting may result in
confusion if voters are familiar with the cumulative voting method, and
think this has something to do with Debian's count rules.
3) It is not necessary to define 'cumulatively preferred' unless it is used
as part of a voting method definition, and I'd need to see the whole method
in order to judge the merits of your system. I am aware of only one (truly
excellent) pairwise method which makes use of a similar concept called
'beatpaths', that may interest you. One possible definition of Schulze's
beatpath method is as follows:
*
Schulze's Method (brief definition):
Candidate A "beats" candidate B if more voters rank A over B than
vice-versa. The
Re: Constitutional voting, definition of cummulative prefererence
On Tue, Dec 05, 2000 at 05:43:43PM -0600, Norman Petry wrote: One point though -- I recommend that you avoid reference to numerical rankings in the constitutional wording. So long as ballots are submitted by e-mail, it may make sense for voters to number the options. In the future, however, you might use a web interface or some other technique for ordering candidates in which the options don't even have visible numbers, but are ordered graphically, with preferred options at the top, and disliked options at the bottom. If Debian is saddled with restrictive language that requires preferences to be numbered, the constitution might need to be changed again to accommodate the different method(s) of expressing a ranking (or nitpickers might challenge results, etc.). I think it would be better to just use general terms like 'ranked higher' and 'ranked lower', and leave the specifics to an ordinary voters' guide, rather than embed these details in the constitution. Hmm.. the constitution already states that votes are cast by email. [Which makes a lot of sense, when you think about the technologies involved -- email queues, web doesn't, and signing of email is a well established technology.] And, personally, I'm not comfortable with "ranked higher" as a circumlocation. But it's an interesting point you raise. A set of ballots cumulatively prefers option A to option B if: * more individual ballots individually prefer option A to option B than prefer option B to option A, or * There is an option C, where A is cumulatively preferred to option C, and option C is cumulatively preferred to option B. I am not exactly sure why you are defining 'cumulatively preferred' to indicate transitive majority preference between options, so I can't say for certain whether or not this is a good idea, because I don't know what you intend to use it for. I'm aiming for a "minimal change" fix for the apparent ambiguity of the current constitution. I'm thinking about proposing an amendment to the constitution where "Dominates" is defined as strict cumulative preference (A is cumulatively prefered to B and B is not cumulatively prefered to A). 2) The term 'cumulative' implies an additive rather than transitive relationship, so it would probably be better to say 'transitively preferred' rather than cumulatively preferred. Well.. a lattice (the ordering relationship used for numbers) is a transitive relationship. More to the point, I was wanting to contrast cumulative preference with individual preference -- cumulative preference is the effect of considering many votes as a whole, rather than of considering a vote in isolation. Another reason to avoid the term 'cumulative' is that it is frequently used in connection with an inferior multi-winner voting method called 'cumulative voting', in which each voter gets an equal parcel of votes (usually 3 or so), and allocates these as they desire among the candidates (3 on one candidate, 1 each on 3 candidates, etc.) Er.. I hope that clearly specifying the voting process will help avoid this kind of misunderstanding. 3) It is not necessary to define 'cumulatively preferred' unless it is used as part of a voting method definition, and I'd need to see the whole method in order to judge the merits of your system. As I indicated above, I'm considering the implications of explicitly specifying that an option "Dominates" another only where the first option is transitively preferred to the second, but the second is not transitively preferred to the first. [I'm aware that there are many alternate voting methods. But, I think we need to at least consider options based on the "don't fix what ain't broke" approach. If we completely rewrite large sections of the constitution we may create future problems which we won't notice for a year or two.] Thanks, -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Condorcet Voting and Supermajorities (Re: [CONSTITUTIONAL AMENDMENT] Disambiguation of 4.1.5)
On Mon, Dec 04, 2000 at 11:20:15PM -0500, Raul Miller wrote: My point of view is that these two are essentially equivalent: in the N+1 style of voting, a person who thinks that the option isn't the best would vote for further discussion. Well, they might do that, yes. Or else they might think to themselves, well, I'm never going to get my preferred choice, and this isn't bad, so yeah, let's do that. I think that's a valid point of view to hold. Indeed, things could happen this way. [Personally, I'm not sure I'd say Oh well -- if My First Preference was important to me, I'd very likely vote 1: further discussion, 2: yes, 3: no -- this wouldn't have a substantially different effect, unless some of the people who had voted the other way had second thoughts, or unless more people participated in the second vote.] It'd have a substantial effect if a supermajority was required: if 60 of 100 people preferred your second preference, and voted Yes/Further Discussion/No, while 40 people voted Further Discussion/Yes/No, the vote would fail, and you'd be back at the start again. Personally, I doubt this would do you any good: everyone's already likely to have decided on their preference, so you may as well take the compromise rather than trying again and again and again. Similarly, in the counting scheme I proposed, you'd vote: Er.. I've been trying to find your proposal. Let me restate it, then. A single vote is called, with each alternative option in its full form as an option, along with a Status-quo option. Developers submit ballots with each option numbered according to their relative preferences. Votes are counted by first counting how many individual votes rank one option above another option, and a matrix is formed, where M[a,b] is the number of votes that rank option a over option b, and M[b,a] is the number of votes that rank option b over option a. An option has quorum if the number of individual ballots mentioning that option is greater than or equal to the quorum required. An option, a, meets a supermajority of N:1 if M[a,S] M[S,a] * N, where S is the Status-Quo option. The vote is counted by first finding the Smith set, then eliminating all options from the Smith set that don't make quorum or their respective supermajority requirement. If no options remain, the default option, Status-quo wins. If many options remain, they're chosen amongst by using STV, or something similar. This isn't entirely ideal: it'll select the status-quo more often than is probably desirable, but otherwise it's fairly expressive, and doesn't weight any preferences any more than others wherever possible. Consider it more as an example of a way to conduct a single vote that has less flaws than yours, rather than one that's useful as is. No, your view of supermajority isn't good because it affects other options than the status-quo options, and raises the odds that they'll win. An alternative way of looking at it is that there's no way to express a preference towards a non-supermajority vote without that preference counting for three preferences the other way. What if I *don't* feel that strongly about it? Well.. if supermajority decreases the chance that an option will win, then, yes, that does tend to bias things in the direction of alternatives. It's also possible to simply bias the vote towards the status-quo, rather than simply biassing it away from some other option. To avoid this bias, you seem to want to bias things away from the alternatives, and in favor of the choice between the supermajority option, and what you call the status quo option. No, I don't want to avoid bias entirely; if I did I'd be saying let's do away with supermajorities and quorums and just use a straight out Condorcet method of some description. But I think the main benefit of a quorum and supermajority is to bias towards the status-quo, not to bias against that particular possibility. Well, again, my reading explicitly requires a vote with Yes/No/Further Discussion as the only options, and only applies supermajority and quorum to those options. Oh? The only way I see to get that interpretation requires I either: [A] Completely ignore A.3(3), or [B] imagine that A.6(7) somehow says that X stands for only no or further discussion What have I missed? Okay, let me flesh out how I'd conduct a vote that has multiple related alternatives that should be decided on at once. First, since the constitution doesn't say anything about merging distinct votes, I'd require the later alternatives to be phrased as amendments to the first alternative presented, even if this essentially implies ignoring the original proposal and rewriting it from scratch. Once all the alternatives are assembled, and the proposers/sponsors have called for a vote, I'd first form a ballot under A.3(1) that looked like [ _ ] Original proposal [ _ ] First amendment [ _ ] Second amendment
Re: I'm not quitting that easy. (Was: Re: I would like to vote also.)
On Mon, Dec 04, 2000 at 11:41:48AM -0800, Karl M. Hegbloom wrote: You don't have to put my key in the ring if you don't want to. Wait Karl, Karl, Karl. Your new key would have been accepted if you simply got it signed the proper way. Instead, you proposed lots of insecure haphazard schemes to prove who you were to get your key signed the wrong way. No one signed it, so your key is not on the ring. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Condorcet Voting and Supermajorities (Re: [CONSTITUTIONAL AMENDMENT] Disambiguation of 4.1.5)
My point of view is that these two are essentially equivalent: in the N+1 style of voting, a person who thinks that the option isn't the best would vote for further discussion. Well, they might do that, yes. Or else they might think to themselves, well, I'm never going to get my preferred choice, and this isn't bad, so yeah, let's do that. I think that's a valid point of view to hold. On Mon, Dec 04, 2000 at 11:20:15PM -0500, Raul Miller wrote: Indeed, things could happen this way. [Personally, I'm not sure I'd say Oh well -- if My First Preference was important to me, I'd very likely vote 1: further discussion, 2: yes, 3: no -- this wouldn't have a substantially different effect, unless some of the people who had voted the other way had second thoughts, or unless more people participated in the second vote.] On Tue, Dec 05, 2000 at 05:58:47PM +1000, Anthony Towns wrote: It'd have a substantial effect if a supermajority was required: if 60 of 100 people preferred your second preference, and voted Yes/Further Discussion/No, while 40 people voted Further Discussion/Yes/No, the vote would fail, and you'd be back at the start again. Personally, I doubt this would do you any good: everyone's already likely to have decided on their preference, so you may as well take the compromise rather than trying again and again and again. Depends on how I felt on the issue -- I rate things based on my preferences, not based on some abstract expectation about other people's preferences. Similarly, in the counting scheme I proposed, you'd vote: Er.. I've been trying to find your proposal. Let me restate it, then. A single vote is called, with each alternative option in its full form as an option, along with a Status-quo option. Developers submit ballots with each option numbered according to their relative preferences. First note: you don't attempt to distinguish between this is worth redoing and this is not worth redoing, in your status quo. Votes are counted by first counting how many individual votes rank one option above another option, and a matrix is formed, where M[a,b] is the number of votes that rank option a over option b, and M[b,a] is the number of votes that rank option b over option a. Second note: this mechanism won't work for STV (which you suggest using, below). An option has quorum if the number of individual ballots mentioning that option is greater than or equal to the quorum required. An option, a, meets a supermajority of N:1 if M[a,S] M[S,a] * N, where S is the Status-Quo option. Third note: this is something we're still debating. The vote is counted by first finding the Smith set, then eliminating all options from the Smith set that don't make quorum or their respective supermajority requirement. If no options remain, the default option, Status-quo wins. If many options remain, they're chosen amongst by using STV, or something similar. It's interesting that you're throwing quorum into the middle of the vote instead of at the begining or the end. I'm curious: do you have any describable reason for this choice? This isn't entirely ideal: it'll select the status-quo more often than is probably desirable, but otherwise it's fairly expressive, and doesn't weight any preferences any more than others wherever possible. I presume, here, you're talking about the case where we're picking between an option with a supermajority requirement and a case where we're not. And, I presume that a bias towards options with supermajority requirements is something that you don't really care about. Consider it more as an example of a way to conduct a single vote that has less flaws than yours, rather than one that's useful as is. The chief flaw you seem to be addressing is this very point we're debating: what should supermajority mean, when comparing options with different supermajority requirements. No, your view of supermajority isn't good because it affects other options than the status-quo options, and raises the odds that they'll win. An alternative way of looking at it is that there's no way to express a preference towards a non-supermajority vote without that preference counting for three preferences the other way. What if I *don't* feel that strongly about it? Well.. if supermajority decreases the chance that an option will win, then, yes, that does tend to bias things in the direction of alternatives. It's also possible to simply bias the vote towards the status-quo, rather than simply biassing it away from some other option. Unless we are contrasting with an unambiguous reference, bias is a matter of what you're contrasting with. To avoid this bias, you seem to want to bias things away from the alternatives, and in favor of the choice between the supermajority option, and what you call the status quo option. No, I don't want to avoid bias entirely; if I did I'd be saying let's do away
Re: Condorcet Voting and Supermajorities (Re: [CONSTITUTIONAL AMENDMENT] Disambiguation of 4.1.5)
On Tue, Dec 05, 2000 at 12:32:12AM +1000, Anthony Towns wrote: The Condorcet criterion says that if there's a single option that pairwise beats every other option, it should win (assuming there's no supermajority requirement, and quorum is met). That's a relatively weak criterion, all things considered. On Mon, Dec 04, 2000 at 11:35:45PM -0500, Buddha Buck wrote: All things considered just being: -- it doesn't deal with supermajorities -- it doesn't deal with quorum issues -- it doesn't state what should happen if there isn't a single option that pairwise beats every other option. I was refering to this last one. It's what the current A.6(2) and A.6(3) are for. (The Condorcet criterion doesn't say anything about the ambiguous cases we've been talking about) I thought we'd agreed that they are to ensure that the Smith criterion is met (which is more specific than the Condorcet criterion). If A.6(3) is supposed to reduce the options to the Smith set, it is very poorly written. I guess this depends on whether you think that Dominates means pairwise beats or transitively beats. I think it means transitively beats. I do see that other people (you, anthony) disagree with me, and I think that's sufficient reason to consider a constitutional amendment to resolve this issue. [I'd like to achieve agreement on a few other issues, however, before I propose anything formal.] Thanks, -- Raul
Constitutional voting, definition of cummulative prefererence
I would like to know if anyone have a specific problem with the following concept of cumulative preference: An individual ballot prefers option A to option B, if: (*) Option A is mentioned at some preference, and option B is not mentioned at all, or (*) Option A is mentioned at a lower cannonical preference number than option B. [For example: 1st is a lower cannonical number than 5th, so a ballot which rated option A as its 1st preference and option B as its 5th preference would prefer option A to option B.] A set of ballots cumulatively prefers option A to option B if: * more individual ballots individually prefer option A to option B than prefer option B to option A, or * There is an option C, where A is cumulatively preferred to option C, and option C is cumulatively preferred to option B. If you disagree with this concept, please let me know -- either privately or on the list. [And: please express yourself as unambiguously as possible.] Thanks, -- Raul
RE: Constitutional voting, definition of cummulative prefererence
Raul Miller wrote:
I would like to know if anyone have a specific problem with the following
concept of cumulative preference:
An individual ballot prefers option A to option B, if:
(*) Option A is mentioned at some preference, and option B is not
mentioned at all, or
(*) Option A is mentioned at a lower cannonical preference number than
option B. [For example: 1st is a lower cannonical number than
5th, so a ballot which rated option A as its 1st preference and
option B as its 5th preference would prefer option A to option B.]
This is a clear definition of 'prefers', which is better than the existing
constitutional wording in that it indicates how truncated ballots should be
handled. Clarifying this is a good idea if the constitution is amended, and
your interpretation is the same as the one that Debian is currently using,
based on my analysis of previous voting results. Treating unranked
candidates the same as if they had been ranked equally in last place is also
the assumption we always make on the Election-Methods list. It is always
desireable to assume this meaning with pairwise methods, otherwise a voter
who truncates will not effectively indicate any preference between his
ranked and unranked choices, and this will have unintended results. For
example, it would be generally unreasonable to assume that if someone votes:
ABC
out of five candidates {A,B,C,D,E}
that s/he actually considers E to be as good as A, yet that's how this vote
will be treated if the method doesn't assume the ranked candidates are
preferred to unranked! In other words, interpreting this ballot to mean:
ABC(D=E)
would be sensible; interpreting it as:
ABC, (A=D=E), (B=D=E), (C=D=E)
would not. This would have no effect in a method like STV, but for pairwise
methods it is a critical issue. Fortunately, it appears that Debian has
been handling this correctly all along.
One point though -- I recommend that you avoid reference to numerical
rankings in the constitutional wording. So long as ballots are submitted by
e-mail, it may make sense for voters to number the options. In the future,
however, you might use a web interface or some other technique for ordering
candidates in which the options don't even have visible numbers, but are
ordered graphically, with preferred options at the top, and disliked options
at the bottom. If Debian is saddled with restrictive language that requires
preferences to be numbered, the constitution might need to be changed again
to accommodate the different method(s) of expressing a ranking (or
nitpickers might challenge results, etc.). I think it would be better to
just use general terms like 'ranked higher' and 'ranked lower', and leave
the specifics to an ordinary voters' guide, rather than embed these details
in the constitution.
A set of ballots cumulatively prefers option A to option B if:
* more individual ballots individually prefer option A to option B than
prefer option B to option A, or
* There is an option C, where A is cumulatively preferred to option C,
and option C is cumulatively preferred to option B.
I am not exactly sure why you are defining 'cumulatively preferred' to
indicate transitive majority preference between options, so I can't say for
certain whether or not this is a good idea, because I don't know what you
intend to use it for. However:
1) Almost all pairwise methods deal exclusively with whether one option A is
preferred/beats/defeats/dominates another, but this is a simple option-pair
comparison that does not imply any sort of transitivity. To define most
pairwise methods, it is important to precisely define this simple
relationship and label it; Debian's existing term, 'dominates' is as good as
any.
2) The term 'cumulative' implies an additive rather than transitive
relationship, so it would probably be better to say 'transitively preferred'
rather than cumulatively preferred. Another reason to avoid the term
'cumulative' is that it is frequently used in connection with an inferior
multi-winner voting method called 'cumulative voting', in which each voter
gets an equal parcel of votes (usually 3 or so), and allocates these as they
desire among the candidates (3 on one candidate, 1 each on 3 candidates,
etc.) Using this term in connection with pairwise voting may result in
confusion if voters are familiar with the cumulative voting method, and
think this has something to do with Debian's count rules.
3) It is not necessary to define 'cumulatively preferred' unless it is used
as part of a voting method definition, and I'd need to see the whole method
in order to judge the merits of your system. I am aware of only one (truly
excellent) pairwise method which makes use of a similar concept called
'beatpaths', that may interest you. One possible definition of Schulze's
beatpath method is as follows:
*
Schulze's Method (brief definition):
Candidate A beats candidate B if more voters rank A over B than
vice-versa. The
Re: Constitutional voting, definition of cummulative prefererence
On Tue, Dec 05, 2000 at 03:24:34PM -0500, Raul Miller wrote: An individual ballot prefers option A to option B, if: (*) Option A is mentioned at some preference, and option B is not mentioned at all, or (*) Option A is mentioned at a lower cannonical preference number than option B. (This also allows votes like: [1] First preference [2] Reasonable alternative 1 [2] Reasonable alternative 2 [3] Further disucssion say) But yes, that's how I understand it. A set of ballots cumulatively prefers option A to option B if: * more individual ballots individually prefer option A to option B than prefer option B to option A, or * There is an option C, where A is cumulatively preferred to option C, and option C is cumulatively preferred to option B. This is combining two definitions needlessly. Better to use a term like `dominates' and just declare it to be: `An option (A) dominates another (B) if more individual ballots individually prefer option A top option B than prefer option B to option A.' What you've defined above is called a beatpath, and in circular ties there'll be beatpaths from A to B (directly say) and from B to A (via C, say). Some Condorcet methods go on to define the strength of a beatpath, and chooses a winner based on the strength of the various beatpaths. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Thanks to all avid pokers out there'' -- linux.conf.au, 17-20 January 2001 pgpbxhtWgE1TG.pgp Description: PGP signature
Re: Constitutional voting, definition of cummulative prefererence
On Tue, Dec 05, 2000 at 05:43:43PM -0600, Norman Petry wrote: One point though -- I recommend that you avoid reference to numerical rankings in the constitutional wording. So long as ballots are submitted by e-mail, it may make sense for voters to number the options. In the future, however, you might use a web interface or some other technique for ordering candidates in which the options don't even have visible numbers, but are ordered graphically, with preferred options at the top, and disliked options at the bottom. If Debian is saddled with restrictive language that requires preferences to be numbered, the constitution might need to be changed again to accommodate the different method(s) of expressing a ranking (or nitpickers might challenge results, etc.). I think it would be better to just use general terms like 'ranked higher' and 'ranked lower', and leave the specifics to an ordinary voters' guide, rather than embed these details in the constitution. Hmm.. the constitution already states that votes are cast by email. [Which makes a lot of sense, when you think about the technologies involved -- email queues, web doesn't, and signing of email is a well established technology.] And, personally, I'm not comfortable with ranked higher as a circumlocation. But it's an interesting point you raise. A set of ballots cumulatively prefers option A to option B if: * more individual ballots individually prefer option A to option B than prefer option B to option A, or * There is an option C, where A is cumulatively preferred to option C, and option C is cumulatively preferred to option B. I am not exactly sure why you are defining 'cumulatively preferred' to indicate transitive majority preference between options, so I can't say for certain whether or not this is a good idea, because I don't know what you intend to use it for. I'm aiming for a minimal change fix for the apparent ambiguity of the current constitution. I'm thinking about proposing an amendment to the constitution where Dominates is defined as strict cumulative preference (A is cumulatively prefered to B and B is not cumulatively prefered to A). 2) The term 'cumulative' implies an additive rather than transitive relationship, so it would probably be better to say 'transitively preferred' rather than cumulatively preferred. Well.. a lattice (the ordering relationship used for numbers) is a transitive relationship. More to the point, I was wanting to contrast cumulative preference with individual preference -- cumulative preference is the effect of considering many votes as a whole, rather than of considering a vote in isolation. Another reason to avoid the term 'cumulative' is that it is frequently used in connection with an inferior multi-winner voting method called 'cumulative voting', in which each voter gets an equal parcel of votes (usually 3 or so), and allocates these as they desire among the candidates (3 on one candidate, 1 each on 3 candidates, etc.) Er.. I hope that clearly specifying the voting process will help avoid this kind of misunderstanding. 3) It is not necessary to define 'cumulatively preferred' unless it is used as part of a voting method definition, and I'd need to see the whole method in order to judge the merits of your system. As I indicated above, I'm considering the implications of explicitly specifying that an option Dominates another only where the first option is transitively preferred to the second, but the second is not transitively preferred to the first. [I'm aware that there are many alternate voting methods. But, I think we need to at least consider options based on the don't fix what ain't broke approach. If we completely rewrite large sections of the constitution we may create future problems which we won't notice for a year or two.] Thanks, -- Raul
