[EM] VoteFair Ranking software version 6.0 in C++ with MIT license

[VoteFair]

Kristofer ~

It occurs to me that you might be thinking that the VoteFair Ranking 
SOFTWARE provides the definition of VoteFair popularity ranking.  That 
is not the case.

VoteFair popularity ranking is defined in two of my books -- "The 
Creative Problem Solver's Toolbox" and "Ending The Hidden Unfairness In 
U.S. Elections" -- and in the Condorcet-Kemeny ("Kemeny-Young") 
Wikipedia article.

Those definitions should make it clear to anyone who understands 
mathematics that the difference between VoteFair popularity ranking and 
the method John Kemeny published is that Kemeny counts opposition and 
VoteFair counts support, and that otherwise the two methods are 
mathematically equivalent.

If you think that the VoteFair Ranking SOFTWARE does not correctly 
calculate VoteFair popularity ranking results, please recognize -- as I 
have said before -- that you (or anyone) can increase the constant that 
specifies how many choices are calculated according to the full VoteFair 
popularity ranking method.

As I have said before, I choose a smaller value for that constant 
because the software is intended for use in real-life voting situations 
where other complications arise as more important than issues of 
mathematical "purity."

So, to repeat, VoteFair popularity ranking IS mathematically equivalent 
to the Condorcet-Kemeny method, and the VoteFair Ranking software can 
calculate either the pure VoteFair popularity ranking results or results 
that only rarely differ from the pure VoteFair popularity ranking 
results. The choice is determined by the constant.

As another option, if someone prefers that the VoteFair Ranking SOFTWARE 
is ALWAYS mathematically pure -- according to the VoteFair popularity 
ranking definition -- and never consumes too much computation time, then 
they can reduce the limit on the maximum number of choices to something 
like 12 choices, and also change the constant (referred to above) to 12. 
  Then the software will NEVER depart from VoteFair popularity ranking 
as defined in my books and in Wikipedia.

Is this distinction between method and software clear?  If not, please 
clarify your concern, and specify whether you are referring to the 
method or the software.

Thanks,

Richard Fobes


On 1/10/2020 3:30 AM, Kristofer Munsterhjelm wrote:
> On 06/01/2020 06.19, VoteFair wrote:
>> On 1/5/2020 5:48 AM, Kristofer Munsterhjelm wrote:
>>> Do you agree with my point about the use of the term "mathematically
>>> equivalent"? If the method appears to be equivalent, that might give the
>>> impression that you don't need to care about cycles at all.
>>
>> VoteFair popularity ranking IS mathematically equivalent to the
>> Condorcet-Kemeny method. The difference is that John Kemeny described
>> the version that counts disapprovals (and finds the smallest sequence
>> score), whereas VoteFair popularity ranking counts approvals (and finds
>> the largest sequence score).
>>
>> The VoteFair Ranking software does calculate the full version (of
>> VoteFair popularity ranking) to the extent that the
>> "global_check_all_scores_choice_limit" value is as large as desired.
>>
>> I choose to leave that value at 6, even though it could be set to 20 or
>> higher with no execution errors.  Of course in that case it would be
>> helpful to insert code that checks for time delays and shows progress in
>> case a Condorcet cycle is slowing it down.
>
> What you seem to be saying is that the objective function (what you're
> trying to optimize), when taking into account the direction of the
> optimization, is the same, so the problem is mathematically equivalent.
>
> That's right. But that doesn't suffice to make the *solution function*
> mathematically equivalent. If it did, then likewise any approximation to
> e.g. Traveling Salesman would be mathematically equivalent with solving
> Traveling Salesman itself, just because it counted the total distance
> the salesman has to travel the same way.
>
> VoteFair may *approximate* Kemeny, and it may use an equivalent scoring
> function, but for any value of the constant, there exist an infinite
> number of inputs for which the outputs will disagree.
>
> Note that this isn't about "likely to disagree". Mathematically, if
> there's a single difference between two functions' mapping, then the
> functions are different. This holds regardless of the implementation
> (because a mathematical mapping is agnostic to how it's implemented).
> E.g. both Insertion and Merge sort implement the mapping from unsorted
> lists to stably sorted ones, but the algorithms themselves are very
> different.
>
>> I'm not sure what you mean by:
>>> ... that might give the
>>> impression that you don't need to care about cycles at all.
>>
>> Neither the method nor the software implies that cycles are of no
>> importance.
>
> Someone who reads "mathematically equivalent" as "proven to give the
> same results" will think that there are no inputs for which the outputs
> differ. Thus he may think that there's no need to be on the lookout for
> strange behavior under certain conditions.
>
> I seem to recall that around 2010, Warren thought that you were claiming
> that VoteFair did exactly reproduce Kemeny results/optima (for every
> election, i.e. not an approximation). There was then a long thread about
> NP-hardness and whether or not determining the Kemeny winner is NP-hard
> (which it is). I *think* you reached the conclusion that VoteFair was an
> approximation, but I don't clearly remember.
>
> The point is, Warren's a mathematician and got confused about what
> "mathematically equivalent" meant as you used it. I'd imagine a
> non-mathematician would have even less chance of getting it right.
>
> And if he understands "mathematically equivalent" that way, and think
> VoteFair always returns the Kemeny optimum, then he's not going to
> think that "oops, I have to be careful about *these* elections", because
> there's nothing to be careful about. After all, it's equivalent, so
> shouldn't it return the correct outcome for every election? VoteFair
> itself doesn't give any indication of when the results are suspect and
> should be thrown out for a tie instead, either.
>
> (I'd suggest replacing the insertion sort code with an integer
> programming solver (like Math::LP::Solve or Math::GLPK) and setting a
> timeout. Such a solver either returns the optimum or says "couldn't do
> that in the time given". It's equivalent over the domain where it
> returns a result, and outside of that domain, it clearly times out.
>
> Or more generally, alter the code so that instead of returning a
> possibly-right result always in finite time, always returning a right
> result but sometimes taking a very long time about it. A timeout is
> easier to diagnose than a result that looks right but isn't. But if
> you're going to do that, why not use an integer programming solver?)
>