I think your questions are answered here: https://electowiki.org/wiki/River On Sat, Mar 9, 2024 at 8:34 PM Michael Ossipoff <email9648742@gmail.com> wrote: > > > On Sat, Mar 9, 2024 at 15:50 Closed Limelike Curves < > closed.limelike.curves@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@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@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 >>> >> ---- > Election-Methods mailing list - see https://electorama.com/em for list > info >