Page MenuHomePhabricator

Use bc in STV algorithm
Open, Needs TriagePublic


From T288740: SecurePoll: Inconsistencies in how we calculate and display small numbers

PHP is inconsistent with precision. As reported, it might save an E-21 precision number in one round but only an E-17 in another.

Bug 2
In the results log of 20_9_5000_439818328, candidate 9's earned votes are stored as 0.0, when in fact they are of the order of ~4.80449350E-17 (calculated with bc from the keep factors in round 13).

Compare this to 20_9_5000_1730013084, where even smaller numbers (such as 7.810096726086052E-21) are being stored accurately.

Using bc would allow for better precision in this kind of math.

I believe bc comes w/PHP these days (at the very least it's available on my stock docker image so presumably it's available on whatever versions of PHP we're running elsewhere) so it should just be a question of whether or not we want to implement it.

Event Timeline

Change 713964 had a related patch set uploaded (by STran; author: STran):

[mediawiki/extensions/SecurePoll@master] Implement bc in STV algorithm

@STran Checking out this change locally, I am not sure I am seeing the correct results.

Master branch elects candidate 1, 2, 3 and 4. Candidate 4 is reported as receiving ~1.5E-5 in round 3. This is also consistent with what OpenSTV reports at default precision (6 d.p.?)

This patch elects candidate 1, 2 and 3. Candidate 4 is reported as not receiving any votes in round 3 and so is eliminated.

blt file for reproduction.

Change 713964 abandoned by STran:

[mediawiki/extensions/SecurePoll@master] Implement bc in STV algorithm


not actively working on it