Skip to content

incorrect treatment of nonstrict preferences #7

Description

@guenterrote

40 votes of type "a=b c" ought to be treated like 20 votes of type "a b c" plus 20 votes of type "b a c".
Judging from the source code, they are treated like 20 votes of type "a c" plus 20 votes of type "b c".
(It is great that the source code is so clearly structured!)

I am attaching two files eqq2.blt and eqq.blt, in which this situation is embedded in a larger example.

A and B have keep values of roughly 50%. Thus, of the 40 votes "a=b c", only
40 * 0.5 * 0.5 = 10 votes should be transferred to C, after electing A and B (and G).
This is not enough to push C through, and A,B,D,E,G get elected.

With "a=b c" in the file eqq.blt, too many votes are transferred to C, and C is elected.

(I have written a python program where I implemented the quadratic-time procedure "Implementing a suggestion of Meek's",
Eivind Stensholt, Voting matters - Issue 16, Paper 2, February 2003,
https://www.votingmatters.org.uk/ISSUE16/P2.HTM
but it is not cleaned up. This works for Meek, but not for Warren. For Warren I know nothing short of trying all permutations.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions