You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@steve.apache.org by Daniel Gruno <hu...@apache.org> on 2015/04/02 15:51:44 UTC
couple of edits to how STV works
HI folks,
I made a couple of changes to the STV method today:
- Fixed an issue wherein if no one was 'lowest', STV would break
- Set the random seed to actually be random now. Setting it to 0 is just
bad juju and can be reverse engineered to place candidates in such a way
that a tie will always favor candidate X.
- Shuffling candidates before picking the lowest in case of a real tie -
alphabetical order should not play into this.
- Fixed a typo where in 'ran' was set instead of 'rand'.
I don't think this has influenced any board elections or such, as the
votes have to be a true tied vote right down to identical total
preference for two or more candidates, but I thought I'd fix it nonetheless.
With regards,
Daniel.
Re: couple of edits to how STV works
Posted by Daniel Gruno <hu...@apache.org>.
On 2015-04-02 18:40, Jim Jagielski wrote:
>> On Apr 2, 2015, at 12:39 PM, Jim Jagielski <ji...@jaguNET.com> wrote:
>>
>>
>>> On Apr 2, 2015, at 9:51 AM, Daniel Gruno <hu...@apache.org> wrote:
>>>
>>> HI folks,
>>> I made a couple of changes to the STV method today:
>>>
>>> - Fixed an issue wherein if no one was 'lowest', STV would break
>>
>> Can you point to the revision number for that? thx
> I see http://svn.apache.org/r1670902, but you said you
> fixed it (or maybe I'm misunderstanding what you mean
> by fixed it and that STV "would break") :)
Yes, that revision fixes the error when it can't find a lowest scorer,
in which case 'which' never gets set and the comparison function breaks
because it expects 'which' to be a Candidate class. I ran some
simulations, which repeatedly broke when there was a tie between the two
bottom candidates, and this revision (r1670902) addressed that issue.
With regards,
Daniel.
Re: couple of edits to how STV works
Posted by Jim Jagielski <ji...@jaguNET.com>.
> On Apr 2, 2015, at 12:39 PM, Jim Jagielski <ji...@jaguNET.com> wrote:
>
>
>> On Apr 2, 2015, at 9:51 AM, Daniel Gruno <hu...@apache.org> wrote:
>>
>> HI folks,
>> I made a couple of changes to the STV method today:
>>
>> - Fixed an issue wherein if no one was 'lowest', STV would break
>
>
> Can you point to the revision number for that? thx
I see http://svn.apache.org/r1670902, but you said you
fixed it (or maybe I'm misunderstanding what you mean
by fixed it and that STV "would break") :)
Re: couple of edits to how STV works
Posted by Jim Jagielski <ji...@jaguNET.com>.
> On Apr 2, 2015, at 9:51 AM, Daniel Gruno <hu...@apache.org> wrote:
>
> HI folks,
> I made a couple of changes to the STV method today:
>
> - Fixed an issue wherein if no one was 'lowest', STV would break
Can you point to the revision number for that? thx
Re: couple of edits to how STV works
Posted by Jim Jagielski <ji...@jaguNET.com>.
> On Apr 2, 2015, at 6:13 PM, Greg Stein <gs...@gmail.com> wrote:
>
> On Thu, Apr 2, 2015 at 8:51 AM, Daniel Gruno <hu...@apache.org> wrote:
>> ...
>
>> - Set the random seed to actually be random now. Setting it to 0 is just
>> bad juju and can be reverse engineered to place candidates in such a way
>> that a tie will always favor candidate X.
>>
>
> I disagree with this change. This now means you/me could run the report and
> get different results. That is even worse than the extreme likelihood
> somebody could rig the vote.
Some implementations ask the person running the s/w whether
to have the person chosen "at random" or for the person
to pick someone to eliminate.
>
> You could simply look at the result as: the algorithm chose it that way. It
> happens to use a pseudorandom sequence to make the choice. That decision is
> *part* of how the algorithm operates, rather than using a true random
> number.
>
>> ...
>
> Cheers,
> -g
Re: couple of edits to how STV works
Posted by Mike Kienenberger <mk...@gmail.com>.
The results of an election should be repeatable.
If there's a seed involved, it needs to be part of the election
results, and it needs to be something that can be specified as a
starting point when re-running the election computation.
On Fri, Apr 3, 2015 at 4:22 AM, Daniel Gruno <hu...@apache.org> wrote:
>
>
> On 2015-04-03 00:13, Greg Stein wrote:
>>
>> On Thu, Apr 2, 2015 at 8:51 AM, Daniel Gruno <hu...@apache.org> wrote:
>>>
>>> ...
>>> - Set the random seed to actually be random now. Setting it to 0 is just
>>> bad juju and can be reverse engineered to place candidates in such a way
>>> that a tie will always favor candidate X.
>>>
>> I disagree with this change. This now means you/me could run the report
>> and
>> get different results. That is even worse than the extreme likelihood
>> somebody could rig the vote.
>
> See r1671014 as a compromise - that way the seed stays the same no matter
> how many times you tally, but cannot be determined beforehand.
>
> With regards,
> Daniel.
>
>
>>
>> You could simply look at the result as: the algorithm chose it that way.
>> It
>> happens to use a pseudorandom sequence to make the choice. That decision
>> is
>> *part* of how the algorithm operates, rather than using a true random
>> number.
>>
>>> ...
>>
>> Cheers,
>> -g
>>
>
Re: couple of edits to how STV works
Posted by Sam Ruby <ru...@intertwingly.net>.
On Fri, Apr 3, 2015 at 4:22 AM, Daniel Gruno <hu...@apache.org> wrote:
>
> On 2015-04-03 00:13, Greg Stein wrote:
>>
>> On Thu, Apr 2, 2015 at 8:51 AM, Daniel Gruno <hu...@apache.org> wrote:
>>>
>>> ...
>>> - Set the random seed to actually be random now. Setting it to 0 is just
>>> bad juju and can be reverse engineered to place candidates in such a way
>>> that a tie will always favor candidate X.
>>>
>> I disagree with this change. This now means you/me could run the report
>> and
>> get different results. That is even worse than the extreme likelihood
>> somebody could rig the vote.
>
> See r1671014 as a compromise - that way the seed stays the same no matter
> how many times you tally, but cannot be determined beforehand.
+1
> With regards,
> Daniel.
- Sam Ruby
>> You could simply look at the result as: the algorithm chose it that way.
>> It
>> happens to use a pseudorandom sequence to make the choice. That decision
>> is
>> *part* of how the algorithm operates, rather than using a true random
>> number.
>>
>>> ...
>>
>> Cheers,
>> -g
>>
>
Re: couple of edits to how STV works
Posted by Greg Stein <gs...@gmail.com>.
On Fri, Apr 3, 2015 at 3:22 AM, Daniel Gruno <hu...@apache.org> wrote:
> On 2015-04-03 00:13, Greg Stein wrote:
>
>> On Thu, Apr 2, 2015 at 8:51 AM, Daniel Gruno <hu...@apache.org>
>> wrote:
>>
>>> ...
>>> - Set the random seed to actually be random now. Setting it to 0 is just
>>> bad juju and can be reverse engineered to place candidates in such a way
>>> that a tie will always favor candidate X.
>>>
>>> I disagree with this change. This now means you/me could run the report
>> and
>> get different results. That is even worse than the extreme likelihood
>> somebody could rig the vote.
>>
> See r1671014 as a compromise - that way the seed stays the same no matter
> how many times you tally, but cannot be determined beforehand.
>
Good idea. Sure, that works for me!
Thx,
-g
Re: couple of edits to how STV works
Posted by Daniel Gruno <hu...@apache.org>.
On 2015-04-03 00:13, Greg Stein wrote:
> On Thu, Apr 2, 2015 at 8:51 AM, Daniel Gruno <hu...@apache.org> wrote:
>> ...
>> - Set the random seed to actually be random now. Setting it to 0 is just
>> bad juju and can be reverse engineered to place candidates in such a way
>> that a tie will always favor candidate X.
>>
> I disagree with this change. This now means you/me could run the report and
> get different results. That is even worse than the extreme likelihood
> somebody could rig the vote.
See r1671014 as a compromise - that way the seed stays the same no
matter how many times you tally, but cannot be determined beforehand.
With regards,
Daniel.
>
> You could simply look at the result as: the algorithm chose it that way. It
> happens to use a pseudorandom sequence to make the choice. That decision is
> *part* of how the algorithm operates, rather than using a true random
> number.
>
>> ...
> Cheers,
> -g
>
Re: couple of edits to how STV works
Posted by Greg Stein <gs...@gmail.com>.
On Thu, Apr 2, 2015 at 8:51 AM, Daniel Gruno <hu...@apache.org> wrote:
>...
> - Set the random seed to actually be random now. Setting it to 0 is just
> bad juju and can be reverse engineered to place candidates in such a way
> that a tie will always favor candidate X.
>
I disagree with this change. This now means you/me could run the report and
get different results. That is even worse than the extreme likelihood
somebody could rig the vote.
You could simply look at the result as: the algorithm chose it that way. It
happens to use a pseudorandom sequence to make the choice. That decision is
*part* of how the algorithm operates, rather than using a true random
number.
>...
Cheers,
-g