|
Boost : |
From: christopher diggins (cdiggins_at_[hidden])
Date: 2005-03-30 23:28:29
----- Original Message -----
From: "Joel de Guzman" <joel_at_[hidden]>
To: <boost_at_[hidden]>
Cc: <kalin.eh_at_[hidden]>
Sent: Wednesday, March 30, 2005 11:03 PM
Subject: [boost] Re: logo contest status query
> Alright, we might need a little more time. Kalin (the one who
> volunteered on doing the tally), sent me a tally. However,
> IRV poses a special challenge because of the number of entries
> involved. It would be nearly impossible to get a "majority vote".
>
> Hence, we would have to do more tallies, iteratively until either
> the winner has a "majority vote" or we reach the 5th iteration
With all due respect you clearly are misunderstanding how IRV works. The
iterations may most definitely continue after five iterations, and that is
clearly to be expected when there are numerous choices. I would suggest
rereading the algorithm description at http://www.fairvote.org/irv/faq.htm .
Specifically the section: "How does it work? Voters rank candidates in order
of choice: 1, 2, 3 and so on. It takes a majority to win. If anyone receives
a majority of the first choice votes, that candidate is elected. If not, the
last place candidate is defeated, just as in a runoff election, and all
ballots are counted again, but this time each ballot cast for the defeated
candidate counts for the next choice candidate listed on the ballot. The
process of eliminating the last place candidate and recounting the ballots
continues until one candidate receives a majority of the vote. With modern
voting equipment, all of the counting and recounting takes place rapidly and
automatically."
IRV is guaranteed to provide a winner.
> (since we have 5 preferences for each voter). I'm guessing we'll
> reach a 5th iteration.
>
> <<<This makes me think that IRV is not suitable for this type
> of voting, and we should reconsider next time we have to do
> this again.>>>
IRV is perfectly suitable for this type of voting.
-Christopher Diggins
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk