> If Yes I don't understand what > happens when > someone who has delegated his vote recieves a delegation on the same > question. I did not thought at this issue. :-) But the answer is quite simple : we *know* that the participant who receives a delegation has delegated his vote and to whom, so we simply follow the delegation chain and add the vote to the correct delegate.
Ok However, should we store the original delegated participant, or the
final delegate after applying closure on the delegation graph of this question? I don't know.
I don't think you can store only the final delegate because if anyone in the chain changes its delegation one would miss it. If one stores only the original delegated participant, one can follow the chain to obtain the final vote. However, I don't know how to cope with the situation when someone in the delegation chain changes its vote. A possible approach require to maintain a structure of the delegations. You then need two functions. One function computes the voting position of a user (it uses either his own vote of it computes the position of the person at the end of the delegation chain). The second function detects who is affected when a person changes is delegate vote/delegate person. Thus, when a person changes his delegate vote/delegate person , all those affected have their vote re-computed by calling the first function. The data structure is simple but very big: for each question Q, and for each person P, it contains the list of persons who have delegated to P on Q... Does this make sense? Félix It is probably much easier and simpler to
store the final delegate. And thus the delegator would know that his chosen delegate has himself delegated to another person. But, on the other side, it would be much more exact to store the exact choice of the delegator, in case the chosen delegate changes his mind. And this raises the question of which information to return when the server is asked about the delegate: information about the wanted delegated? or the effective delegate? I need to think about this issue. Good spot Félix! :-) Best wishes, d.
_______________________________________________ Demexp-dev mailing list Demexp-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/demexp-dev
