Editing Talk:Task:Define voting procedure for Community Council elections

Warning: You are not logged in. Your IP address will be recorded in this page's edit history.

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.

Learn more about Contributing to the wiki.

It seems we don't have TeX enabled here...
Dumping original content here, and will edit the main page to render it readable. If we get TeX, this may be pasted back...
== Proposal: RRV ==
=== Variables ===
*<math>l</math>: number of voters
*<math>m</math>: number of candidates
*<math>n</math>: number of seats
*<math>i</math>: index of voters (<math>1 \le i \le l</math>)
*<math>j</math>: index of candidates (<math>1 \le j \le m</math>)
*<math>k</math>: index of seats (and rounds) (<math>1 \le k \le n</math>)
=== Parameters ===
A range for votes is selected by two limits, <math>a_{max}</math> and <math>a_{min}</math>.
Reasonable choices include:
*<math>a_{min}=0</math>, <math>a_{max}=1</math> (unbalanced, normalized)
*<math>a_{min}=-1</math>, <math>a_{max}=1</math> (balanced)
*<math>a_{min}=0</math>, <math>a_{max}=100</math> (unbalanced percentage; potentially useful if ratings were to be quantized) 
The effects of the voting system are generally independent of the limits selected, but a balanced range ''may'' be preferred by some voters to permit unknown candidates to be rated 0 with known, disliked candidates rated negative. Obviously this effect may be accomplished in an unbalanced range by rating unknown candidates <math>\tfrac{a_{min} + a_{max}}{2}</math>. Some calculations are simplified by using the unbalanced, normalized range, which makes it preferable from a numerical perspective.

A ballot from voter <math>i</math> consists of <math>m</math> ratings <math>a_{ij}</math> for the <math>m</math> candidates, such that <math>a_{min} \le a_{ij} \le a_{max}</math>.

=== Procedure ===
After all ballots are collected, <math>n</math> rounds are held to choose the winners <math>w_{k}</math>, with one winner chosen per round. In the first round, the weighted ratings for each voter are initialized as <math>b_{ij1}=a_{ij}</math>. The weighted scores in each round are summed:

The highest-scoring candidate not yet elected wins; this is not simple to express formally:

<math>w_k = \max ( B_{jk} \ni j \notin w_{1 \cdots k-1})</math>

The weighted scores for each succeeding round are calculated by de-emphasizing ballots according to the portion in which they've already won:

<math>b_{ij(k+1)}=\frac{a_{ij}}{1+\sum_{p=1}^{k}\tfrac{a_{iw_p}-a_{min}}{a_{max}-a_{min}}}</math>

In the case of an unbalanced range (<math>a_{min} = 0</math>), <math>b_{ij(k+1)}=\frac{a_{ij}}{1+\sum_{p=1}^{k}\tfrac{a_{iw_p}}{a_{max}}}</math>, and in the normalized case (<math>a_{max} = 1</math>), <math>b_{ij(k+1)}=\frac{a_{ij}}{1+\sum_{p=1}^{k}a_{iw_p}}</math>.

=== Discussion ===

It seems to me like this voting system requires voters to understand at least a little game theory. It looks far too complicated to be used in a real-life election.

The voting system used should, in my opinion, require the voter to do one of three things:
* Choose candidates in order of preference (1, 2, 3...)
* Choose 1 favourite candidate
* Choose their N favourite candidates from the electorate (the GNOME system)

Of the three choices, the GNOME system is my least favourite, and the straight vote seems a little limiting. I prefer simple preferential voting.

Of the simple preferential voting systems, my favourite is single transferable vote. It's better than Condorcet, in my opinion, because it is understandable quite easily by the electorate and does not produce unexpected results (such as someone who was no-one's favourite candidate getting elected).

--[[User:dneary|Dave Neary]] 18:39, 3 December 2008 (UTC)

Please note that all contributions to maemo.org wiki may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see maemo.org wiki:Copyrights for details). Do not submit copyrighted work without permission!

Summary:

Cancel | Editing help (opens in new window)

Retrieved from "https://wiki.maemo.org/Talk:Task:Define_voting_procedure_for_Community_Council_elections"

@@ Line 48: / Line 48: @@
 --[[User:dneary|Dave Neary]] 18:39, 3 December 2008 (UTC)
-:From the voter's perspective, I don't see score ballots as requiring more game theory knowledge than ranked ballots. Both require voters assigning numbers to some or all candidates, but preferential ballots make it ''more'' complex, by adding constraints on those numbers. All voters have to do (perhaps I wasn't clear on this, as I was emphasizing the underlying mechanics) is assign a score from 0 to 1 (ideally continuous, but possibly discretized) to each candidate, reflecting the value they assign to that candidate's winning.
-:I think score ballots are better because they are simpler and more expressive. Since there are no possible invalid ballots, there is no need to keep the ballot valid (by dynamically altering the voter's previous input), or to reject invalid ballots (and throw the voter back to fix the invalid ballot). The score ballot also carries more information because it preserves the relative magnitude of preferences, while ranked methods consider only the direction.
-:Another ballot system you didn't mention is approval ballots (the extreme discretization of score ballots; simply a checkbox by each candidate); these enjoy all the simplicity of the GNOME system, but are intermediate in expressiveness with preferential ballots, so I'd rate them a more desirable choice than GNOME. They also inherit from score ballots the lack of invalid ballots, allowing a simpler voting process than either preference or GNOME; however, I'm not real sure on other counting methods for approval ballots (besides, obviously, the reweighting algorithm as proposed).
-:As for "far too complicated", are you referring to the voter's perspective, or the implementation of the scoring mechanics? If the latter, it may be because I (a non-mathie) was trying to state things formally.  I considered whipping up some C or Octave code to demonstrate, and can still do that if it's helpful. It seems substantially simpler to me than effective STV counting methods, such as Meek counting, and has the benefit of being deterministic and finite-depth, making it seem more likely to be numerically robust, and simple to implement. (I'm also aware of substantially less work on multi-winner score-ballot methods, so the proposed reweighting may be gaining simplicity at the cost of using the ballot information less efficiently than Meek/STV does, but the additional information expressed in score ballots does compensate for this...) --[[User:benson|benson]] 23:10, 3 December 2008 (UTC)

Personal tools

Navigation

Views

Editing Talk:Task:Define voting procedure for Community Council elections