Voting system R&D (Re: 2017 update to the SPI voting algorithm	for Board elections)
    Ian Jackson 
    ijackson at chiark.greenend.org.uk
       
    Sat Mar  4 15:47:26 UTC 2017
    
    
  
Henrik Ingo writes ("Re: Voting system R&D (Re: 2017 update to the SPI voting algorithm for Board elections)"):
> Purely as a FYI on Schulze method, it is implemented in the Liquid
> Feedback system: http://liquidfeedback.org/
Thanks.  That's interesting.  I wasn't aware of that.  I think Liquid
Feedback is very exciting.  It is an innovative system used by
politically oriented organisations who understand governance problems
well.
But I think in SPI we probably want to be more conservative.
In particular, Scottish STV (a traditional STV variant) has some
important advantages for us over Schultze STV:
 * The specification of Scottish STV is expressed in readily
   comprehensible prose, as opposed to mathematics.
 * We already have multiple independent implementations of Scottish
   STV.  (Note that Markus has not provided the actual source code of
   his implementation AFAIC T1])
 * Scottish STV is considerably simpler.  My reimplementation in Perl
   is 432 lines.  Markus's implementation of Schultze STV in C++ is
   6000-7000 lines, depending on which variant we use.
 * Traditional STV (including Scottish STV specifically) has a large
   body of independent analysis - not just of the voting system from a
   mathematical/technical level, but also of the sociopolitical
   effects such as effects on voting patterns and on attitudes in the
   polity.
My personal view is that a more Condorcet-ish proportional voting
system is a good thing, but that I would like to see more third-party
analysis.  I do have the skills to follow Martin's paper myself, but
digging into this in detail is not a personal priority for me right
now.
In any case, the differences in outcome between Schultze STV and
Scottish STV are likely to be minor.
Thanks,
Ian.
[1] There is the file http://m-schulze.9mail.de/schulze3.zip whilch
contains (at least) four different variants, which have obviously been
generated from a single original source file.  Neither that original
source file nor the machinery for substuting the variants is in the
zipfile.
    
    
More information about the Spi-general
mailing list