Redesign nonIntegerWinningThreshold and hareQuota in GUI and add new validation rule

[HEdingfield]

• Per mock-up, these settings will only be enabled for multi-winner, and the two check boxes will be replaced by a 3-way radio button.
• Non-Integer Winning Threshold = false and Hare Quota = false:
  • Compute using most common threshold formula
    = ((Votes/(Seats+1))+1, disregarding fractions
• Non-Integer Winning Threshold = true and Hare Quota = false:
  • Compute using HB Quota
    > (Votes / (Seats +1))
• Non-Integer Winning Threshold = false and Hare Quota = true:
  • Compute using Hare Quota
    = (Votes / Seats)
• Non-Integer Winning Threshold = true and Hare Quota = true:
  • This will become an invalid combination that needs to be rejected during validation.

Relevant discussion:

@chughes297:

We made this a radio button because you can technically run an election using both Hare and HB Quotas but that doesn't exist in law anywhere and it's (as far as I know) never been used in elections because Hare is outmoded as a threshold. So we wanted to foreclose the ability to combine those as thresholds. happy to discuss further, though.

@HEdingfield:

Louis / Jon, do you agree that we should get rid of the possibility of both Hare Quota and Non-Integer Winning Threshold both being set to true? If so, do we add validation to prevent this, potentially invalidating past configs, and also change the docs in the .txt? Or do we leave it as a possibility via manually-edited config files and not via the GUI?

@tarheel:

Fine with me. Yeah, let's just add validation for it.

@HEdingfield:

Our documentation (see below) doesn't seem to 100% match the formulas listed in the radio button options here.The formulas differ subtly, and it also seems that there should be a fourth option (where both values are true), right? If so, what's the wording you want? And how do you want to correct the wording for the other ones?

"nonIntegerWinningThreshold" optional
the vote threshold used to determine winners can be a non-integer
if true, threshold = V/(S+1) + 10^-d
if false, threshold = floor(V/(S+1)) + 1
where V = total number of votes (in the current round for single-seat or in the first round for multi-seat); S = numberOfWinners; and d = decimalPlacesForVoteArithmetic
(note that S+1 in the formulas above becomes just S if hareQuota is set to true)
value: true | false
if not supplied: false

"hareQuota" optional
the winning threshold should be computed using the Hare quota (votes divided by seats) instead of the preferred Droop quota (votes divided by (seats+1))
only valid for multi-seat contests
value: true | false
if not supplied: false

@chughes297:

the precise expression of the non integer winning threshold formula (aka the Hagenbach-Bischoff Quota) is just votes/(seats+1) and does not require the addition of any value to the threshold. we found the explanation in the mockup to be most effective at communicating the concept to people. would capturing that mean changing code? or do we need to add that small extra amount to the value to make the threshold function?

@tarheel:

I don't remember all the details of the discussion, but I believe I implemented the threshold logic based on extensive guidance from Caleb and George.
I think the rationale for adding the 10^-d part is that the candidate's tally needs to be at least that much greater than the threshold in order to be considered to officially exceed it, given the decimalPlacesForVoteArithmetic setting. So we say that a candidate won if their tally is greater than or equal to V/(S+1) + 10^-d. But I think that in practice this distinction shouldn't matter as long as we're applying decimalPlacesForVoteArithmetic correctly, because if 10^-d is the smallest level of granularity we're allowing for numbers, you should never have a tally that's greater than the threshold but less than (threshold + 10^-d). Does that make sense?

@moldover:

Yes, that is the logic, and I presume statute requires the small 'epsilon' amount to be added so I would keep it.

@HEdingfield:

Sounds like we're converging on "yes" to limit to only the 3 situations outlined in the mock-up, but also sounds like we need definitive wording on the final version. Can someone please copy from the mock-up, edit it, and send it my way?

@chughes297:

Briefly discussed - thinking we could maybe just change the written description to >votes/(s+1) instead of ≥. We are not too concerned about a technical difference in how the tabulator calculates the actual threshold value and feel that this re-write of the description captures the function of the rule without possibly getting too complex. 

[HEdingfield]

Note changes made in #500 overlap with this to some degree (i.e. "Non-Integer Winning Threshold" is disabled unless winnerElectionMode is "Multi-winner allow only one winner per round" or "Multi-winner allow multiple winners per round").

[HEdingfield]

Closed with #512.