Dominion Voting Systems

[enhzflep]

Errors can at times be the hardest thing to get right. Any fool can insert a bug accidentally.

[Stephen Gonzalez]

Who you want to be fired? The Dev who made the count variable to be 'float'? What makes you think it's Dev problem? What if it's intentionally done from upper management. IMHO, I think the Chief should be fired. :laugh:

The best way to make your dreams come true is to wake up. Paul Valery

[r_hyde]

I'm not taken aback at all, in fact I'll go as far as to say that it might be the best way to design such a system! The idea that Dominion stores vote counts in a floating-point format seems to come from a NIST publication[^] describing a reporting standard. I don't think it's been proven that the Dominion software uses the described format, though I would not find it at all surprising if it did. This is an open standard, the creation of which involved the expertise of very smart, thoughtful, and experienced people, probably with strong knowledge of the problem domain. They are named as authors, if you question their work you may look them up and contact them to find out for yourself what their motivations were. The standard specifies that aggregate vote counts are reported as double-precision floating-point numbers, which it says "can include a f[r]actional component in special cases" (though the nature of such special cases is not described). How individual votes are stored in the machines is not specified (as this is intended as a generalized rather than machine-specific standard), the document only addresses how counts are aggregated for the purpose of reporting. Even if individual votes were recorded by a voting machine as a floating-point whole number (again, a fact which is not in evidence), it would require astronomically more addition operations than there are voters (let alone people) in the U.S. in order to reach a rounding error of even a single vote. In short, you can't possibly be certain that there's a problem here, but even your worst case scenario would result in effectively zero inaccuracy in the reported counts from the various Dominion systems in use.

[jsc42]

Obviously done by the same folks who 'designed' the UK Track & Trace app; who thought that passing the data on an Excel XLS spreadsheet was a good idea as they never considered that there would be more than 16384 (or 65356 depending on which version of Excel they were using) cases to record in a day.

[F ES Sitecore]

Yeah but you're forgetting about the dead....they can vote too ;)

[mngerhold]

I don't think we know that for a fact - the press widely reported something along those lines, but...

[Daniel Pfeffer]

OK, so remove one doubling. I'll also be retired in 3035. :D

Freedom is the freedom to say that two plus two make four. If that is granted, all else follows. -- 6079 Smith W.

[James Curran]

Yep, it's nonsense. I've tracked this down as best I could. The origin seems to be this (nearly 5 year old) article in Black Box Voting: [Fraction Magic — Part 2: Context, Background, Deeper, Worse – BlackBoxVoting.org](https://blackboxvoting.org/fraction-magic-2/) It seems that one person (a developer and poll worker) noticed that in his precinct, if you subtract the "number of people who didn't vote in this race" from the "total people who voted" (yielding the total who DID vote in that race), that number was one more than the number you get if you add up all the voted each candidate got. (since that race had 199 write-ins, it quite believable that one write-in wasn't readable and didn't make the counts, which would explain that -- but our guy doesn't like simple solutions). He figured it must be a floating-point round-off error!! So, he read thru Diebold's (Yes, this is about Diebold -- not Dominion!) apparently public bugtrak database (from 2001!), and spotted a few bugs related to decimal places in their outputs --- and he concluded that the votes were being tabulated in floating point. In reality, they were actually talking about where they display the PERCENTAGE of the vote each candidate got, which, in these days of ever closer elections, must be given in multiple decimal place. SO, to conclude: There is ZERO evidence that any voting system manufacture uses floating point to count votes.

Truth, James

[Bruce Patin]

I'm taken aback. Actually, I think that all election software should be entirely open source and verified by real programmers. Also, this technique of moving numbers from a scanner to an aggregator by little SD cards leaves too much room for sleight of hand. And ballots in Pennsylvania have bar codes. Whether or not they can be associated with an individual voter I don't know. There is one state using all mail in voting in which the voters themselves can login and verify that their vote has been recorded properly. Things can be so much improved. Having RCV and better candidates would help a lot.

[englebart]

Reminds me of a lottery programming scam. On certain days of the year, it would use a different, predictable algorithm to generate the winning numbers. The authorities caught on after multiple relatives hit million dollar jackpots.