Other website?

[Adam Tarr]

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 
site.

>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.

-Adam


----
For more information about this list (subscribe, unsubscribe, FAQ, etc), 
please see http://www.eskimo.com/~robla/em