Condorcet-to-Scalar using MinMax (was: [EM] Displaying intermediate results in Condorcet-based elections)

[Gervase Lam]

> From: Gervase Lam <gervase at group.force9.co.uk>
> Subject: Re: [EM] Displaying intermediate results in Condorcet-based
> elections Date: Fri, 31 Oct 2003 02:34:09 +0000

> I've thought of another way of doing this without using Kemeny-Young.  I
> should have thought of this earlier: 'Plain' Condorcet.

I should definitely have thought of this earlier.  Forest beat me to it by 
about 5 hours.  As I am on the digest version of the mailing list, I 
didn't get to see it before I posted the above.

> I'll assume that the weakest pairwise win is the pairwise contest where
> a candidate has obtained the highest number of votes and still lost the
> pairwise contest.

I should have said the weakest pairwise win is the pairwise contest where 
a candidate was defeated with (not "by") the least number of votes.  I was 
trying to explain MinMax using "winning votes".  This is not it.  I 
suppose this is what could be called "losing votes".

There is one thing that I THINK could be a problem with "winning votes" on 
a web site that displays running MinMax results.  If the end user sees the 
"winning votes" scalar scores before and after submitting a ballot, the 
end user may not see a change in the "winning votes" scores.  In other 
words, the ballot submitted by the end user changes the bits of the result 
matrix that does not involve the "winning votes" scalar scores.

Using margins effectively halves the matrix.  The user submitting the 
ballot will then definitely change the scalar scores as one ballot will 
definitely change all of the bits of the halved matrix.

However, the advantage of "winning votes" is that it could be said that it 
is a half secret ballot.  A single ballot only changes half of the matrix. 
 Therefore the end user has to do some guess work or cleverly work out how 
to make major changes to the result.

If "winning votes" scores were used, a single submitted ballot would 
change, on average, half of the scores.  In some cases, it could be more, 
possibly even all of the scores could be changed.  In some cases, it could 
be less, possibly even none of the scores would be changed, as I described 
earlier as the worst case scenario.

I don't think it is worth working out probabilities here as it depends on 
who the candidates are and how close or decisive a ballot turns out to be. 
 Or put another way, I can't be bothered to!  Nevertheless, I think the 
probabilities can be extremely low for the worst case scenario.

Also, the distinction between "winning votes" and "margins" in Rob Brown's 
demo voting web page is less than what you would "normally" get.  Not 
allowing candidates to be given equal rankings is the biggest cause of 
this lessening.  However, it seems that any candidates who are unpicked 
will be given a ranking of equal last.

I am sure there is a way to display equal rankings clearly.  Each 
candidate always has move up and move down buttons beside it.  Therefore, 
one click of move up could merge the candidate with the candidate above.  
This would cause both the candidates to appear in one green box with the 
ranking changed to, for example, T3 for tied 3rd.  Another click would 
unmerge the candidates.  Obviously, a similar thing would happen when move 
down is clicked.  I think this would be very clear to the end user.

The problem with this idea is what should happen when an unpicked 
candidate goes from the unpicked list to the picked list.  Should it 
automatically merge with the bottom ranked candidate in the picked list or 
should it be given a ranking of its own at the bottom of the picked list?

The advantage of merging on picking is that end user immediately realises 
that equal ranking is possible.  The disadvantage is that it could be more 
frustrating if the end user wishes to submit a the ballot with no equal 
rankings.  The user would have to click move up or down after each pick.  
Also, equal rankings requires noticeably more coding.

If equal rankings were to be allowed, I think merge on picking is the best 
way.  If the merge isn't done on picking, the end user could build up a 
ballot without realising that equal rankings are actually allowed.  Though 
the user could be frustrated with the merge on picking when building a 
ballot with no equal rankings, at least the user immediately realises that 
equal rankings is possible and doesn't feel cheated because the end user 
hasn't noticed that equal rankings are allowed.

To a certain extent I prefer the up/down and pick/unpick buttons.  With 
drag and drop, it is not immediately obvious that the candidates need to 
be dragged and dropped to create a ranking.  All you immediately see are a 
list of candidates.  Buttons immediately prompt you that they need to be 
clicked in order for something to happen.  Also, drag and drop sometimes 
feels like it needs good aiming in order to move a candidate between two 
other candidates.

> I'm not too sure whether it is necessary to drop all of the pairwise
> contests involving the winner [when building up a MinMax ranking of
> candidates].  One reason to do this is because once there is a winner,
> we want to know who is the best out of the remaining candidates.
>
> On the other hand, I can see the possibility of candidates being tied if
> the winner's pairwise contest[s] are dropped.  An advantage of not 
> dropping the [winner's] pairwise [contests] is that the second placed
> candidate is then also compared with the winning candidate.

Forest more or less suggested not bothering with dropping the pairwise 
contests of the "winners" in order to determine the overall ranking of the 
candidates in this case.  I think this is probably a good idea.

Imagine that there is a Condorcet winner.  You then have to do something 
"special" in order to give the Condorcet winner a score.

Next, you need to find the candidate who is ranked 2nd.  The pairwise 
contests involving the Condorcet winner are dropped.  What if this results 
in "another" Condorcet winner?  You then have to do something "special" 
again and so on.

Thanks,
Gervase.