[maemo-community] Election process referendum
From: Benson Mitchell benson.mitchell at gmail.comDate: Sun Feb 1 02:41:45 EET 2009
- Next message: Election process referendum
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Tue, Jan 27, 2009 at 8:19 AM, Andrew Flegg <andrew at bleb.org> wrote: > On Tue, Jan 27, 2009 at 11:28 AM, Benson Mitchell > <benson.mitchell at gmail.com> wrote: > > > [range vs. preferential ballots] > > if, e.g, a voter has already ranked candidate A as 3rd, and then ranks > > candidate B as 3rd, is candidate A devoted, or pushed down to 4th? > > This should be a validation error in the web front end, and the user > has to correct it. Presumably the same would apply to any range voting > where the number entered was outside the range (i.e -10 or 1000), or > any of these methods which are more complex than "just select your > most preferred candidate" which have direct number input. > Well, actually I was assuming a range ballot for online voting would use radio buttons or a slider control, which inherently limit possible inputs to valid inputs. OTOH, I was assuming radio buttons for ranking, which don't constrain input to validity. One possible input scheme for an auto-validating preferential ballot is dual-list-boxes with >> and << buttons to add/remove candidates, and vertically exchanging them in the ballot side. I hadn't really considered how UI-dependent that criticism is... > > > The counting method, and its implications on voter strategy, however, > gives > > RRV a more significant edge. With STV, many situations arise where voting > > for your favored candidate may hurt his chances of election (versus > voting > > against him or not voting at all); the honest strategy can be seriously > > counterproductive. The voter _must_ try to predict the outcome to know if > > one of these situations is occurring, and alter their vote for maximum > > strategic effect. If they misjudge or disregard this, their honest > > participation may worsen the outcome. > > I've heard this asserted, and seen pages on scorevoting.net which try > to prove it, but a quick analysis doesn't have me convinced. > > Can you explain how this "hurt your preferred candidate(s)" situation > occurs? > > Essentially, it comes down to the fact that candidates are eliminated from the bottom by a criterion unrelated to their actual success; winners are determined by accumulating first-choice and transfered votes to reach a quota, but losers can be eliminated simply from not having enough votes in the _current_ round, regardless of whether they could still receive enough transferred votes to reach the quota. Since candidates are only eliminated when no candidate meets the quota, this effect is prevalent as the ratio of candidates to seats increases (resulting in more dilution of votes). The pages on scorevoting.net, of course, are principally about the single-seat cases of STV (IRV) and of RRV (RV), which make for the simplest such cases, but the same principles apply with multi-seat versions and proportionately more candidates. It's trivial to concoct a ballot where a certain candidate (call him A) gets the fewest 1st-choice votes, but is everyone else's second pick, and the first round is closely matched between the other candidates -- if nobody makes the quota, A, who quite likely should be elected to one of the slots, will be eliminated in the first round. It's a little trickier to see the exact circumstances required for a participation failure, but essentially if some other candidate (say, B) had a razor's edge quota, and then you add a handful of A supporters. Now B has the same number of votes, but the quota is larger, and he no longer makes it; now A is eliminated, and the A-supporter's votes transfer to their second choices. If those candidates had stayed home, however, A could have picked up enough second-choice votes to win a seat. Some nice pictures for these concepts are here<http://www.rangevoting.org/IrvExtreme.html>; the Yee diagrams show the resulting winners for a population randomly distributed about any point in a 2-d candidate space, and you can see a lot of places where the wrong candidate flatout wins (because the "right" candidate got eliminated), and even more where the actual winner is highly sensitive to voting noise. (Those pictures are from computer simulations with 5000 voters, and we didn't even have 1000 last election, so we would expect potentially worse results.) > > <snip> > > > 3) Accuracy/optimality of results. (As I haven't heard any disagreement > on > > this point, I won't spend much time here.) > > > > Range voting is, in my view, unambiguously superior in the single-winner > > case, both logically and empirically. While there's currently no accepted > > performance metric analogous to Bayesian regret for multi-winner > elections, > > it stands to reason that as the logical multi-winner extension of range > > voting, RRV should be one of the best options available. > > The maths behind Bayesian regret seems spot on. I'm not convinced that > it accurately models how people *feel*. An election method needs to be > more than just a mathematical model which is provably optimal. > Certainly, and there's two lines of attack to show that the model is unsuited to reality: First (the one you seem to be thinking), is that the model depends on modeled voter behavior that does not correspond to actual voter behavior. Essentially, though, the model assumes nothing about how people's utility scales work, or whether they make sense; it only assumes that they will vote in rational accordance with their utility, i.e., with how they feel. So the place this would break down, if it were to, is not with people irrationally assigning values to outcomes (that's handled fine), but if they prefer a certain outcome and irrationally vote against it. _If_ that sort of irrationality holds true in enough cases to matter, it does invalidate the Bayesian regret numbers, but it also renders *any* voting system ineffective. The second, and IMO more interesting, line of attack lies on the notion that you can model the general utility as the uniformly weighted average utility of voters. This is not generally expressed directly in isolation, and it took me a while to pinpoint it, but Bayesian regret is predicated on this egalitarian axiom. (In political elections, there are almost no plausible exceptions; the obvious ones of race, gender, etc. are generally out of consideration. In a software community, however, it's conceivable some would argue, e.g., that developers' utility should be weighted heavier than end-users, or that content-creators should outweigh both.) However, range voting is robust against this argument as well, simply because no obvious election method will favor any particular class drawn along those lines; the only obvious ways to achieve such results is controlling suffrage, not voting methods, and once the weighting (supposting it were desired) was established through controlled suffrage, Bayesian regret analysis could be validly applied to the remaining voters. While I find this whole line of reasoning quite interesting. it really has no direct application here, as suffrage is already fixed, and I don't really see a genuinely desirable bias anyway. On Sat, Jan 24, 2009 at 8:36 AM, Andrew Flegg <andrew at bleb.org> wrote: > On Fri, Jan 23, 2009 at 2:40 PM, Dave Neary <dneary at maemo.org> wrote: > > > > We can run a referendum election for changes to theh voting procedure > > pretty quickly, and as was pointed out already, we should probably get a > > move-on. > > Assuming the three options I outlined ("No change", "STV" and > "Neither") have consensus, or aren't argued with, by Sunday, 1st > February 2009 then we > ^^^^^^^^^^^^^^^^^^^^^^^^^ > enact the referendum to start then and run for 1 month. This gives us > over a week for debate. > Apologies to all for being so late with this reply; we are getting close to the proposed time. I'll try to stay a *little* more on top of discussion these next few days. :-) So far, I think Dave, Andrew, and I have spoken out on this... anyone else have opinions? (I'm gonna go bump the itT thread as well...) Benson -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.maemo.org/pipermail/maemo-community/attachments/20090131/8e2cbf61/attachment.htm
- Next message: Election process referendum
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]