| Bram Cohen ( @ 2005-05-15 22:54:00 |
flow based voting
Here's an idea for a ranked ballots voting algorithm. We imagine each voter has a little water spigot which puts out water at a unit rate, and each candidate has a bucket the size of the droop quota. Each candidate turns their spigot to the bucket of the candidate highest on their list. When a bucket gets filled, everyone who was pouring water into it redirects their spigot to the bucket of their next-higher candidate. This continues until all buckets are filled. The candidate whose bucket finished filling last is then scratched off everyone's ballots, and the process is repeated, scratching off candidates until there are only as many candidates left as there are positions available.
This technique is conceptually very simple and easy to analyze (albeit computationally a bit intensive, but that's hardly a concern with modern hardware). It also does very well at some basic gameability criteria. For example, the extent to which a voter can increase the power of their vote by putting a heavily disfavored candidate first is minimized. Also, if there's a block of voters who have picked out a slate they can't get any advantage as a group by playing games with how they arrange the candidates on their ballots. The water output for the group is fixed, and if they have just barely enough votes to get their candidates in and noone else votes for their candidates and they put all members of their slate before all non-members of their slate then they will manage to exactly get their slate in, regardless of ordering of their votes within the slate and after the slate.
My thanks to Paul Crowley, who first suggested the water flow analogy, although he did so in the context of trust metrics, not voting systems.
Here's an idea for a ranked ballots voting algorithm. We imagine each voter has a little water spigot which puts out water at a unit rate, and each candidate has a bucket the size of the droop quota. Each candidate turns their spigot to the bucket of the candidate highest on their list. When a bucket gets filled, everyone who was pouring water into it redirects their spigot to the bucket of their next-higher candidate. This continues until all buckets are filled. The candidate whose bucket finished filling last is then scratched off everyone's ballots, and the process is repeated, scratching off candidates until there are only as many candidates left as there are positions available.
This technique is conceptually very simple and easy to analyze (albeit computationally a bit intensive, but that's hardly a concern with modern hardware). It also does very well at some basic gameability criteria. For example, the extent to which a voter can increase the power of their vote by putting a heavily disfavored candidate first is minimized. Also, if there's a block of voters who have picked out a slate they can't get any advantage as a group by playing games with how they arrange the candidates on their ballots. The water output for the group is fixed, and if they have just barely enough votes to get their candidates in and noone else votes for their candidates and they put all members of their slate before all non-members of their slate then they will manage to exactly get their slate in, regardless of ordering of their votes within the slate and after the slate.
My thanks to Paul Crowley, who first suggested the water flow analogy, although he did so in the context of trust metrics, not voting systems.