bd on Fri, 8 Dec 2006 13:14:56 -0700 (MST)

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: [s-d] [s-b] Proposal: conflicts and dependencies

Daniel Lepage wrote:
> On Dec 7, 2006, at 11:17 PM, bd wrote:
>>> For every set of two Won Proposals which Conflict each other, the one
>>> with the lower Number becomes Lost.
>> Hm, what happens if you have three proposals, say, 100, 101, 102,  
>> such that:
>> 100 Conflicts with 101.
>> 102 Conflicts with 101.
>> And all passed.
>> 100 and 102 can go in together, or 101 can do in, but it looks like in
>> this case only 102 will go in - since, between 100 and 101, 100 will
>> lost, and between 101 and 102, 101 will lose. This seems suboptimal
>> somehow, but I'm not sure how to fix it...
> Work from the high end down. In this case, start with 102: it  
> conflicts with 101, so 101 becomes Lost.
> Then 101 conflicts with 100, but 101 is already Lost, so we ignore  
> that. Thus, 100 and 102 will pass.
> You could still have a problem where 103 - 110 are all fine, but 111  
> conflicts with all of them, and everything passes, but I think that's  
> ok: we have to give precedence somehow, and by number seems  
> appropriate. Or we could sort by fewest number of conflicts, and then  
> by number. Or we could make weirder criterion, if we wanted to make  
> this gameplay (Sort by score decreasing, then voting power  
> increasing, then name reverse alphabetically....).
> Also, I doubt we will get many complicated cases. I think this will  
> usually be used just for sets of mutually exclusive proposals.

How about solving for the fewest number of votes (or smallest amount of 
voting power) that would need to be changed to make the system 
consistent? That is, for each subgraph of conflicting proposals, look 
for the one with the smallest gap between FOR ang AGANST votes, make 
that Lost, and repeat until everything works out.

spoon-discuss mailing list