One Citizen: One Vote. PERIOD. We no longer have 3/5ths of a person
The days of that are over
THere are no "fracitons". If there's a fraction. EVEN ONE, including point zero .0, is flawed.
It's an enormous data problem that suggests that the process is flawed. There are no 3/4 of a vote. There are no .66 of a vote. or .01 of a vote
ONE PERSON, ONE VOTE
Meaning that we should be using WHOLE NATURAL NUMBERS
There is NO process where there should be a fractionalization of the numbers.
If there is math involved and you have 10 votes and you count 3/4 of that 10, then the .5 of 7.5 is dropped and should be 7
You don't Round (7.5 => 8, 7.4 => 7)
You Floor (the opposite of round 7.5 => 7) that way it's consistent, the fraction is essentially ALWAYS SPOILED
If you have a process that involves DIVISION or MULTIPLICATION, then YOUR PROCESS IS ALREADY FLAWED -- tell us why a process would even involve multiplication or division---it's already UNCONSITITIONAL because these processes result in fractions.
SOLUTION
The process involved in TALLY should ONLY include ADDITION
I've seen the data declarations, and it's just lazy programming (and design).
The voting system provides support for distributing a single vote among multiple candidates, because there are elections held that way in the US:
https://en.wikipedia.org/wiki/Cumulative_voting
But, for a normal election, the field should be declared as an integer (or long, depending on the architecture of the underlying hardware). All operations should be simple addition.
If you declare a value as floating point, you can't guarantee it will remain a value that can be represented by an integer.
The problem: floating point arithmetic in base 2 results in small errors creeping into the result, especially over millions of calculations. And once a fractional error creeps into the result, it may not be able to be represented exactly in base 2, resulting in more errors.