atarr at purdue.edu
Mon Feb 10 20:32:32 PST 2003
matt matt wrote:
>You seem to be incorrectly assuming that the margins method has non-voted
>options ranked last like your preferred winning votes method. The margins
>method could place the non-voted options at the approval cutoff.
This would require the voted ballots having an explicit approval cutoff,
which neither of the Condorcet methods most popular on this list (beatpath
and ranked pairs) include.
It's also worth noting that we're not only talking about truncation
here. We're talking about any equal-ranking. Someone could rank, say, A
first, B and C second, D third, and leave E and F off their ballot. In
this case the presence or lack of an approval cutoff is irrelevant. Then
again, if we're using approval-completed Condorcet, then margins vs.
winning votes argument is completely irrelevant.
Your argument strikes me as a bit of a bait-and-switch. You suggested that
both margins and winning votes options be provided. I point out that
margins results can always be generated from winning votes programs. Then
you come back with (badly paraphrasing) "if the margins method requires
some other information besides the ranking, the winning votes program that
only has the ranking information won't be able to duplicate it." Well,
sure, but if you give that same information to a winning votes program,
then once again you can duplicate the margins result using that program.
I initially wrote a whole long tedious and boring explanation here, of how
winning votes can be converted to margins, but not vice versa. Upon
reading it over, it's pretty poorly written and I think it would be a waste
of people's time to read it. If you want to look at it let me know.
Suffice to say that it is essentially impossible to write a winning
votes-based program that can't be converted to margins. On the contrary,
if a program allows truncation in the ballots, and uses defeat margins to
calculate the results, it won't be able to duplicate winning votes results
for a number of methods (including most Condorcet methods).
>There is no way to convert from your preferred winning votes method to all
>variants of margins.
You could convert winning votes to margins in all fourteen of the ranked
ballot variants that are listed on Rob's website
(http://www.onr.com/user/honky98/rbvote/), and that's good enough for me.
Moreover, you could convert to any variant of margins that took the same
ballot input as the winning vote method. In other words, if the only way
two methods differ is in how they measure defeat-strength, then you can
convert winning votes to margins. But not always the other way around.
>In my opinion, it is relatively easy to code a Condorcet method program to
>give the user the choice of measure of defeat.
I agree. It's trivial to convert winning votes to margins, so any program
set up to do the former can be set up to do the latter very
easily. Sometimes the opposite is true as well, although it can be a
little work other times. But it's not too hard.
>So the only reason not to do so is to use the program as a means for
>trying to enforce your preference on other people.
Absolutely not. As Mike argued, offering both options makes things more
confusing for the neophyte. Of course, this is not the only significant
argument. But it's clearly hyperbole to say "only reason not to do so is
to use the program as a means for trying to enforce your preference on
other people." There are other factors to consider.
If someone wrote a program that could do either (or perhaps even listed
both results, just as Eric's program lists the different results of ranked
pairs and beatpath) then this would be fine. I wouldn't have any problem
with such a web site. But such an approach might not be best for every web
>The program should be open source and in the same spirit the program
>shouldn't take sides on technical disputes where knowledgeable people can
>and do disagree as you and Mike when you cite other knowledgeable people
>who appear to prefer margins.
Well, the program, it it's open source, is essentially the baby of whoever
is hosting it, so they can politicize it to their heart's content as far as
I care. You won't catch me complaining bitterly about how Rob's excellent
web site keeps me from calculating winning votes ballots. He has his
(benevolent) agenda, and I don't have any problem with that.
>Furthermore, it seems to me that the choice of method (and variations of a
>method) is logically related to the context. By context, I mean variables
>such as the number of candidates, how well the voters know the candidates,
>how many candidates are to be elected, how often the candidates are
>elected, what authority the elected candidates acquire, how much the
>voters will know in advance about the probable outcome, how much
>opportunity the voters have to engage in individual and colloborative
>strategic voting and the like.
This statement is tied up in the whole winning votes vs. margins debate. I
would argue that the only case where margins is the better choice is the
zero information case, and even then it's only because it makes it easier
to vote for those who are truly indifferent between two candidates. But
this is clearly a discussion for another thread.
For more information about this list (subscribe, unsubscribe, FAQ, etc),
please see http://www.eskimo.com/~robla/em
More information about the Election-Methods