From: | Ian Jackson <ijackson(at)chiark(dot)greenend(dot)org(dot)uk> |
---|---|
To: | Jonathan McDowell <noodles(at)earth(dot)li> |
Cc: | spi-general(at)lists(dot)spi-inc(dot)org |
Subject: | Re: 2017 update to the SPI voting algorithm for Board elections |
Date: | 2017-03-02 17:01:45 |
Message-ID: | 22712.20473.175768.167646@chiark.greenend.org.uk |
Views: | Raw Message | Whole Thread | Download mbox |
Thread: | |
Lists: | spi-general |
Jonathan McDowell writes ("Re: 2017 update to the SPI voting algorithm for Board elections"):
> (I have re-ordered this reply to try and cover the issues relating
> directly to the wording of the resolution first, and moving the less
> time critical discussion about implementation to the end.)
Thanks.
> > Let me try a different wording for that paragraph. How about this:
> >
> > 7. The practical implementation will be by means of software; for
> > example, perhaps the openstv package in Debian. The choice of
> > software is up to the Secretary. However, any differences between
> > the Rules in the Order, and whatever software implementation is
> > chosen, are to be resolved in favour of the Rules.
> >
> > I do think it is important to declare that it is the prose rules which
> > definitive, not the software.
>
> I think that's a much better wording for the paragraph. I agree we want
> the Order to be the authoritative version of the rules implemented.
OK.
> > What do you think of another paragraph like this:
> >
> > The Secretary's current practice is to privately issue each voter
> > with a private token, by construction verifiably distinct from
...
> I'm not really sure it adds anything to the matter at hand. It seems to
> only be documenting the current practice?
Yes. If you don't think it's worthwhile I'll drop it.
> [Implementation discussion]
...
> I think that's very much a measure of last resort; a programmatic
> interface to the Python modules involved would seem a much more robust
> solution. From a deployment perspective the Debian package annoyingly
> pulls in wx and all its associated dependencies, but that can be worked
> around.
Hrm.
> I agree the inputs are under tight control of the membership system but
> I'm less worried about the security than the reliability of the
> implementation; is there confidence that OpenSTV has been deployed for
> use in Scottish STV and found to be reliable? I don't think we want to
> run a couple of elections and then discover that we've been using a
> buggy implementation and have to figure out how to fix it ourselves.
Yes.
Well. I wrote my own implementation of the Scottish STV rules, based
on the Order, and fed a couple of existing SPI tally sheets into both
my ad-hoc reimplementation, and Debian's openstv. I arranged for my
program to generate output which could be compared to that from
openstv. The results were identical. Obviously this is not a
complete test but I am willing to tart up my software if you like, so
we can have two implementations and see if they agree.
> (It would be nice if the Scottish local election voting data was
> available to provide a suitable set of test vectors, but I couldn't
> even find any alternative sources of such test data.)
There was test data for the software used for the Scottish system:
http://www.votingmatters.org.uk/RES/eSTV-Eval.pdf
I have sent two FOI requests to see if the Scottish Executive and/or
the Electoral Commission have it.
https://www.whatdotheyknow.com/request/test_data_for_scottish_single_tr
https://www.whatdotheyknow.com/request/test_data_for_scottish_single_tr_2
Thanks,
Ian.
From | Date | Subject | |
---|---|---|---|
Next Message | Ian Jackson | 2017-03-02 17:11:04 | Re: 2017 update to the SPI voting algorithm for Board elections |
Previous Message | Jonathan McDowell | 2017-03-02 10:13:15 | Re: 2017 update to the SPI voting algorithm for Board elections |