<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<font face="Helvetica, Arial, sans-serif">I think Tideman's original
description calls for the implementor to recursively exhaust over
all permutations of tied margins, and to construct a winner set as
the union of winners under all recursive extensions. This is no
fun. The Handbook of Computational Social Choice (one of my few
books on the subject) says "Whether a given alternative is a
ranked pairs winner... turns out to be NP-complete". (p100.)<br>
I agree that Schulze's method cuts out a lot of pain. I don't
think Tideman himself ever proposed his method for practical use.
<br>
CJC<br>
</font><br>
<div class="moz-cite-prefix">On 06/03/2023 05:26, Kevin Venzke
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:580633778.6792573.1678080401372@mail.yahoo.com">
<pre class="moz-quote-pre" wrap="">Hello,
Colin wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Their specification doesn't say what to do if two pairs have equal margins, although other
forms of tie are at least vaguely described. I assume "there is a tie" means "the margin is
zero", but the language is slightly misleading. Maybe whenever two pairs had equal margins
the AMS resorted to a coin toss between all candidates.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
Incidentally I think this is a considerable advantage of Schulze, that no matter which
approach you use, i.e. the beatpath algorithm or the Schwartz sequential dropping one, you
are able to go through the calculation a single time and you will know whether ultimately
there is a tie and who was in it.
I recently made a calculator that tries to show the steps to solve Ranked Pairs and River
and I couldn't come up with a satisfying way to dedupe all the possible ways that one could
traverse the propositions when there are tied strengths, and potentially many. I settled on
showing up to two traversals per possible winner.
Kristofer wrote under "Why all the fuss?":
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">(Of course, it's not that easy: someone has to actually implement the method -- and the
simulations!)
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
Yes, implementing a complicated method can take some time, and I'm often unsure of the
prospects for a method to be good in some way. (This might even cause me to implement it
wrong due to bad intuition.)
I've seen skimming the recent posts that Forest is proposing a number of methods where
you're pretty much going to look at all the pairwise contests, and there are a number of
points within the course of following the algorithm where the method can take a turn and
lead to a change in outcome. I feel pretty confident at least that such a method, from a
burial incentive standpoint, is not going to be very interesting to Kristofer. It might
work for me, that's true.
One thing I could do is provide a bunch of examples on what methods look like in my
framework, taking the form of a Python 3 class, and then people could just send me methods
if they want. I'm not sure if there would be any takers for that. It would probably be more
interesting if I was maintaining and publishing a big list of results, which at the moment
I'm not. (Partly due to the sensitivity of results to scenario parameters.)
The idea of making some new visuals is interesting. I would like to somehow map the
correlations or apparent trade-offs present in methods' compromise, burial, and truncation
incentive. That's seemingly a 3D plot though.
Kevin
votingmethods.net
----
Election-Methods mailing list - see <a class="moz-txt-link-freetext" href="https://electorama.com/em">https://electorama.com/em</a> for list info
</pre>
</blockquote>
<br>
</body>
</html>