[EM] Easy River definition (also my site is back up)
Michael Ossipoff
email9648742 at gmail.com
Sat Mar 9 20:33:37 PST 2024
On Sat, Mar 9, 2024 at 15:50 Closed Limelike Curves <
closed.limelike.curves at gmail.com> wrote:
> River is actually really easy to explain:
> 1. List all pairwise matches from biggest to smallest margin of victory.
> 2. If a candidate loses a match, cross them out (declare them to be a
> loser). Cross out any redundant matches that involve them (anything that
> would make them get eliminated twice).
> 3. Cross out any elections that would create a cycle.
>
Could that be worded as:
List the defeats, one at a time, stronger ones first.
But skip any defeat that cycles with already-listed defeats.
…& also skip any defeat whose defeated-candidate is defeated in an
already-listed defeat.
When all defeats have been listed or skipped, elect the candidate who isn’t
beaten in a listed defeat.
>
>
> On Sat, Mar 9, 2024 at 2:46 PM Michael Ossipoff <email9648742 at gmail.com>
> wrote:
>
>> Wow. River doesn’t need the exhaustive pairwise-count? How does its
>> count-time compare to that of RP?
>>
>> I didn’t know that about River. I believed that only Sequential-Pairwise
>> was the only exception to the need for the exhaustive pairwise-count.
>>
>> The exhaustive count requires, per voter, counting one pairwise-vote for
>> each possible pair of candidates.
>>
>> How many votes need to be counted per voter in River?
>>
>> If one only cares about finding the winner, rather than an
>> output-ranking, could the count-instruction be written more briefly?
>>
>> As written, it’s much too complicated for a public-proposal.
>>
>> Someone said that River is better at deterring burial. I disagree. It
>> seems to me that skipping a defeat if its defeated is defeated in an
>> already-kept defeat undermines autodeterence.
>>
>> Only one of the CW’s defeats is kept. That means that every Bus but one
>> can’t have its defeat dropped, so only one Bus survives.
>>
>> I like it if the exhaustive pairwise-count isn’t needed, but can the
>> count-instructions be written more briefly, if only the winner is needed?
>>
>> On Sat, Mar 9, 2024 at 07:02 Kevin Venzke <stepjak at yahoo.fr> wrote:
>>
>>> Hi Mike and everyone,
>>>
>>> First off, if anyone was missing my site, it is back up. I had to find
>>> different
>>> hosting (a bit abruptly).
>>>
>>> Where I was trying to link right before the site went down:
>>> votingmethods.net/cond
>>> works out a given (or random) scenario for Schulze, RP, or River. You
>>> just have to
>>> expand sections at the bottom of the result. So it could be worth a look.
>>>
>>> Mike wrote:
>>> > Is River as easy to define &. explain as RP?.
>>>
>>> I see I should try to write out clearly how I suggest to understand
>>> River.
>>>
>>> There is no "final ranking" in River. Instead every candidate begins
>>> "below no one"
>>> or "subordinated to no one." This is sort of a ranking but the "trees"
>>> we make go
>>> only one level down: you will never be able to ascend two positions from
>>> a given
>>> candidate.
>>>
>>> 1. Initially each candidate is subordinated to no one.
>>> 2. Consider each pairwise defeat from strongest to weakest.
>>> 3. When you consider a defeat, ask whether the loser is subordinated to
>>> anyone?
>>> If so: Ignore the defeat and proceed to the next.
>>> If not, then ask:
>>> 4. Is the defeat winner subordinated to the defeat loser? If so, ignore
>>> the defeat
>>> and go to the next.
>>> 5. Is the defeat winner subordinated to someone else? If so, the defeat
>>> loser, along
>>> with everyone subordinated to them, becomes subordinated to the
>>> candidate that the
>>> defeat winner is subordinated to.
>>> 6. Otherwise it must be that the defeat winner is subordinated to no
>>> one. So here
>>> the defeat loser, along with everyone subordinated to them, becomes
>>> subordinated to
>>> the defeat winner.
>>> 7. End loop. Go to the next defeat.
>>> 8. In the end, the candidates subordinated to no one are the winners.
>>>
>>> Alternatively instead of talking about subordination, you can say that
>>> each
>>> candidate has their own "bin" and starts in their own and may move to
>>> another.
>>> This would allow you to merge steps 4 and 5:
>>> "4. The defeat loser, along with everyone *in the loser's bin*, moves to
>>> whichever
>>> bin the defeat winner is currently located in."
>>> And if the latter bin happens to be the loser's bin, in effect nothing
>>> happens. We
>>> don't need a rule saying to ignore the defeat, because the bin movement
>>> doesn't
>>> change anything either.
>>>
>>> I can understand if a reader eyeballs all that and says this looks like
>>> a mess and
>>> it's not clearer than RP.
>>>
>>> But hear me out on the *ease* of it:
>>>
>>> 1. If you are programming River, you never actually check for a cycle,
>>> whether a
>>> proposed defeat would create one. And comparing to Schulze, you never
>>> trace a
>>> beatpath or find its strength, or (by its other algorithm) have to find
>>> the Schwartz
>>> set repeatedly.
>>> 2. If you are solving it by hand, it would be enough to have a fridge
>>> magnet for
>>> each candidate, start them out in imaginary bins, and push the magnets
>>> around in a
>>> straightforward way to track who is subordinated to whom.
>>>
>>> It may be possible to define RP more concisely, but it takes some work
>>> to figure out
>>> what it is actually saying to do to solve it.
>>>
>>> Hopefully the above explains it better than I have before.
>>>
>>> Kevin
>>> votingmethods.net
>>>
>> ----
>> Election-Methods mailing list - see https://electorama.com/em for list
>> info
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.electorama.com/pipermail/election-methods-electorama.com/attachments/20240309/7869e227/attachment-0001.htm>
More information about the Election-Methods
mailing list