Re: Sponsor this
On Tue, Dec 19, 2000 at 09:05:46AM -0600, Norman Petry wrote:
> I think it is better if the method described in the constitution is
> defined in functional terms, rather than in the form of an algorithm.
> Not only is that form of description briefer and easier to understand,
> but it allows the bugs in the implementation to be fixed. If every
> bug in the algorithm used to implement the voting method requires
> a constitutional amendment to change, it's going to be a real PITA
> to maintain. For example, the Smith criterion can be unambiguously
> stated in one or two sentences. If you want to use Smith as a voting
> method, rather than just a criterion the method satisfies (which would
> be better, imho), if you define it in the constitution then a later
> discovery that your algorithm doesn't actually implement smith could
> easily be fixed.
Hmm.. I was trying to match the criteria that the constitution be usable
as psuedo code, and I was trying to eliminate ambiguities as concisely
as possible, given that constraint. If there's some kind of consensus
that I shouldn't use psuedo code that would make it a lot easier on me.
> However, you can see that writing out this algorithm in the Constitution is
> going to be a lot more cumbersome than simply defining what the Smith set
> *is* in one or two sentences.
Smith set is trivial to define in a about four sentences using
transformations on arrays. Here's the concise form:
compute matrix of option x beats option y.
find transitive closure.
add columns, find minimum sum.
eliminate options with sum greater than minimum.
Eliminating ambiguity in the interpretation of those sentences would bulk
them up a bit, but the equivalence still holds. (In the first matrix,
1 indicates that x beats y, 0 indicates not. In the second matrix,
1 indicates that x transitively beats y. The sum corresponding to an
option should indicate the number of options which transitively beat it).
Please note that a number of the ambiguities in the current constitution
result from people treating unfamiliar constraint terminology as psuedo
code. I suppose that, since Debian is composed largely of developers,
that's to be expected.