FRACTION MAGIC VIDEO (Widespread Electronic Voting Fraud Mechanism)

blackboxvoting.org ^ | October 31, 2016 | Bev Harris

[Whenifhow]

PING!!!

Votes are counted as a fraction, then a percentage is allocated to one party. Demonstration of this is at around 12 min mark.

Article and comments

You can watch the video Fraction Magic here:
Fraction Magic on Youtube
https://www.youtube.com/watch?v=Fob-AGgZn44

Bet Harris is a Liberal Democrat and she is convinced that Hillary Clinton is going to steal the election, quote: “If Hillary wins or loses the election, she’s going to win the election,” due to this GEMS imbedded software which has been spread to almost every state. Harris is horrified!

Thanks Swordmaker

[Freedom56v2]

I listened to the Infowars interview—it was geared towards trying to prevent vote fraud. Infowars is huge Trump supporting show—have been pro-Trump since the very beginning (even before FR), so their mission is not to enable Hillary.

[Swordmaker]

Data types are reflective of machine-level CPU capabilities, they’re not arbitrary. You’d need to not only re-invent the wheel, but the wagon it’s attached to and the roads it travels on.

Basically, no current microprocessor manufactured today can eliminate this problem at the level you want it eliminated.

Excuse me, angryoldfatman, but 64 bit computers can handle integer numbers from −(2⁶³) to 2⁶³ − 1, or in base ten, from −9,223,372,036,854,775,808 to +9,223,372,036,854,775,807. That is before we have to start using ANY floating point decimal place math to manipulate the data. That should be able to handle any votes in any election I have every heard of. 64 bit computers are as common as dirt today.

[angryoldfatman]

Product?

[angryoldfatman]

That is before we have to start using ANY floating point decimal place math to manipulate the data.

~~~~~~~~~~~~~~~~~~~~

Also, what data type would this be and how would it be stored in bits and/or bytes?

[angryoldfatman]

OK, I apologize because I have been trying to learn SQL in the past few months, so my ignorance is showing.

I was aware that 64-bit processors could process huge numbers, but I didn’t do the research necessary on data types. I’d been used to DBAs using double-precision, since you never have to make your numbers any bigger after end-users suddenly change their requirements (not that they ever do that... LOL!)

The problem with the voting machine software is that very thing. The guys who set up database software were lazy, uncommunicative, were under unrealistic time constraints, or... were told to enable decimals.

The code monkeys who wrote their apps over that database could use the double-precision numbers, which according to the guys in the video, they did to devastating effect.

For the record, the data type that SHOULD have been used was bigint.

[Swordmaker]

The problem with the voting machine software is that very thing. The guys who set up database software were lazy, uncommunicative, were under unrealistic time constraints, or... were told to enable decimals.

The original versions of GEMS was integer up until versions started to morph in 2004-2005. By 2006 all versions of GEMS included the floating point option choice. As pointed out by Bennie Smith, you can convert any election from Integer count to floating point at the option of the GEMS master user. That should NOT ever be an option.

The Fraction Magic video goes through a list of election races and you can tell which have been manipulated by whether they were converted to floating point or not. Those that were still integer count had not been manipulated, and had no decimal places in their counts. It is as obvious as all hell!

OK, I apologize because I have been trying to learn SQL in the past few months, so my ignorance is showing.

You were thinking in terms of 8 bit or 16 bit processors. . . which were extremely limited, but still could do some amazing things.

I was programming databases 30 years ago and wrote a full-function accounting package about that long ago. . . and handling large numbers with 8 and 16 bit processor computers. . . and you still did not need floating point to handle large numbers. It was just a bit more time consuming to do it. You just had to take large numbers into small enough pieces to handle them. The more pieces the longer it took. That's why the terms were originally spoken of in nibbles, bits and bytes. You took a bit off a nibble of the problem your processor could handle, then went back for another bIte (byte) until you had eaten the whole thing. . . you see the analogy.

[angryoldfatman]

You were thinking in terms of 8 bit or 16 bit processors

~~~~~~~~~~~~~~~~~~~~~~~~~~~~

No, like I said I was perfectly aware of 64-bit capabilities. Don’t insult me now that I’ve apologized, please.

I was talking about SQL, which I was led to believe by a couple of DBAs to be limited by how processors work.

It turns out they were just lazy or CYA (or CTA, to be pedantic). They used double-precision numeric variables whenever they needed anything larger than a few digits.

There is still a data type in SQL that is like what I originally described - smallint.

bigint uses 8 bytes for processing, just like double-precision does.

8 bytes is 8 bytes, no matter how big the word size happens to be.

As an aside, well over 90% of databases in use today are based on two brands of SQL - Microsoft SQL Server and Oracle’s MySQL. These are decades old, and it would be cost-prohibitive to create new application software without using one of them.