# Liquid filtering

Over at agoravoting

We have a situation where we have to collectively choose among many options, this is scaling the solution space. It is infeasible to apply voting as is, because voters cannot consider all these options to make a judgement. So what we do is to distribute the cognitive load in a way that reflects user delegation. The problem of liquid filtering is the assignment of voters to questions according to delegation choices, in an optimal way.

## 4 thoughts on “Liquid filtering”

1. Gérard Bodin says:

No need of an algorithm to solve that. Assuming there is no loop, every voter without delegation has to vote on every question in order to have each question voted by everyone, it is necessary and enough. With loops, each loop can be seen as a super-voter without delegation which therefore has to vote on every question, questions being divided within each loop between its voters.

By the way I think that collaborative filtering *is* sampling indeed. With that delegation approach, one idea could be rejected by only one voter if everyone else has delegated its vote to him, which is acceptable for decision making but not for preliminary filtering.

1. David says:

There are multiple ways of assigning voters to questions, with varying results. The use of an algorithm is to optimize these assignments to minimze the number of questions you need to ask. It’s not just a matter of loops but of the network structure in general. See eg the next post on agoravoting blog (ill be posting it here shortly too)

Yes, collaborative filtering is sampling, but in some cases with implicit delegation (ie inferring user affinity) thrown in.

2. Gérard Bodin says:

I read the next post (but reply here since Agora’s blog don’t accept comments) and I agree: all what matters is topology.

Let’s assume that every voter has one and only one delegate.

If the graph is a giant loop (v1 -> v2 -> v3… -> vN -> v1), then only one vote is required for each question.

On the opposite, if the graph is only isolated pairs [v1 v2, v3 v4,… v(2k-1)v(2k)] then you’ll need as much as N/2 votes for each question in order to have everyone voting.

So, generally speaking: the larger the loops, the less votes you’ll need.

1. David says:

Yes, your observation makes sense, although again it’s a particular instance of a general problem, which is how the topology affects the coverage, and how to distribute the voters optimally given that the topology is not known ahead of time. There are rules of thumb, for example, do not assign voters that are transitively reachable to the same question.

The problem becomes even more interesting when adding things like transitive cutoff, delegation damping and other things mentioned in that post. Another thing we’re looking to do is to construct random graphs that are more realistic to better anticipate the performance.