[EM] A method "DNA" generator, tester, and fixer

[Kevin Venzke]

Hi Kristofer,

--- En date de : Mar 18.5.10, Kristofer Munsterhjelm <km-elmet at broadpark.no> a écrit :
> > I've been working on a new method
> generator/tester/fixer. I did this once
> > before, and my approach is still the same, but now
> truncation is allowed
> > (instead of strict ranking). The old simulation only
> defined methods on
> > 8 scenarios, allowing 6561 possible methods. The new
> simulation defines
> > methods on 27 scenarios, which means 7.6 trillion
> methods.
> 
> Does this thing actually create new methods, as implied by
> the term "generator"? If so, what approach do you use -
> brute force, genetic programming, something different?

Yes, it makes new methods by
1. randomly generating the outcomes of the method
2. attempting to fix criterion problems that are not wanted. Though
some criteria are harder to fix than others. If it can't fix it, the
method is discarded and it starts from scratch.

#2 is pretty important because otherwise with 7.6 trillion possible
methods you would spend forever looking for even slightly usable methods.
For example, two-thirds of that count don't elect the first-preference
winner when everybody bullet votes.

The program is unable to explain the method in English.

> > Here are the criteria at the moment. I can make more,
> and have tried to
> > come up with weakened versions of criteria to try to
> weed out the
> > completely absurd methods from ones which may have
> unusual merits.
> 
> (...)
> 
> It might be possible to rigorously define these criteria in
> the case of three candidates. Say, for the sake of
> simplicity, that there is no truncation, and
> 
> variable = number of voters voting this way:
> 
> a = A>B>C
> b = A>C>B
> c = B>A>C
> d = B>C>A
> e = C>A>B
> f = C>B>A
> 
> Then mono-raise failure could be specified as
> 
> there exists a,b,c,d,e,f so that:
>  a >= 0, b >= 0, c >= 0, d >= 0, e >= 0, f
> > 0
>  method(a, b, c, d, e, f) -> A wins
>  ( method(a, b+1, c, d, e, f-1) -> B wins) OR
>  ( method(a, b+1, c, d, e, f-1) -> C wins)
> 
> with the reasoning that any monotonicity failure can be
> whittled down to the point where a single voter changes his
> preference, and that if the candidates are randomly assigned
> labels A, B, and C, all such failure can also be reduced to
> the case where A is raised. That A is ranked last before the
> change instead of merely second is required to catch methods
> like antiplurality elimination.

Unfortunately the program doesn't have such high resolution that it
can take arbitrary proportions. It only defines methods and tests
criteria on 27 comprehensively interconnected scenarios.

I am not sure what the most natural way to expand the generator would
be. If you add equal ranking at the top, you would support 125 scenarios
instead of 27. You would pretty much need a program to help you find
the definition of a known method. Furthermore I'm not sure how useful
this would really be when you still can only have three factions.

Adding a fourth candidate and bloc would be much harder: 1296 if you
require complete ranking. And that's if you can figure out how to have a
fourth faction at all. I really don't know the easiest way to do that.
But four factions with three candidates would probably be my choice.


Incidentally, speaking of monotonicity: I tried creating a weak form of
LNHarm which says that adding a lower preference can't make *that*
preference win. But I couldn't find any usable method which satisfied
that (while failing LNHarm) and also my "raising to second place" version
of monotonicity. That's too bad. I thought I might find something that
would blow my mind.

Kevin