# Thread: Floating Point Rounding Errors

1. ## Floating Point Rounding Errors

Every base 10 integer can be exactly converted to a base 2 integer. All that the computer needs is enough bits. However, this is not true for fractional numbers. For example, the base 10 fraction 1/100 can be represented as the decimal number 0.01. However, when the same number is converted to binary, it becomes a repeating binary number. The reason that 1/100 cannot be represented exactly in base 2 is similar to the way that 1/3 cannot be represented exactly in base 10; only fractional base 10 numbers that can be represented in the form p/q, where q is an integer power of 2, can be expressed exactly with a finite number of ones (1) and zeros (0).
1. If I understand the quote: every number with a denominator with an integer power of 2 can be expressed without error in binary that is: x/1, x/2, x/4, x/8, x/16, etc can all be converted without error. All other fractions cannot be accurately converted to binary. Is this correct?

2. Is there a test that can be used to determine if a fraction can be accurately converted to decimal?  Reply With Quote

2. yeah,

a fraction a/b can be expressed as a nonterminating decimal if and only if b can be expressed as an integer power of 2 multiplied by an integer power of 5.  Reply With Quote

3. ## Using rational numbers.

For some special computations, rational arithmetic functions have been programmed to avoid the problems caused by never ending binary and/or decimal fractions. It is clumsy and slow, but within limits can be practical.

BTW: Almost all accounting programs work with pennies instead of dollars to avoid this problem.

For fairly good reasons, accountants go nuts when they are off by a penny, which would happen all the time due to amounts like \$5.37 which cannot be expressed in binary. Instead they would use 537 pennies. I think they sometimes use mills, which are 1/10 of a penny or 1/1000 of a dollar. On output, the values are converted to dollars for human consumption.

I have seen programs for producing mutual fund dividend checks which round to the nearest penny, but keep track of the round off error to ten or more decimal places. The program then posts the total round off error to a "round off" ledger entry. When they create thousands of checks totaling millions of dollars, they manage to keep track of all the money down to the nearest penny. For a big mutual fund, the round off error can be several hundred (even a thousand or more) dollars per month. Of course, it averages out to almost zero over a period of years. There have been stories (probably not true but possible) about programmers managing to steal \$20.00 to \$100.00 per month by cute manipulation of the round off ledger entry. The gimmick is to round down for .50xxxx pennies when calculating the amount for a check, but record it in the roundoff ledger as a round up. This allows a penny to be stolen for every one hundred accounts (on average). The money stolen is added to the check for an account belonging to the programmer. Some mutual funds have over one hundred thousand accounts. At best, it is not much, but every little bit helps. Notoica that the owner of an account who knew how to calulate his dividend amount, would proably assume that rounding down for .50xxx pennies was npormal, and would not bother to call it to anybody's attention. Somebody might notice that the round off error was not quite right from a statistical point of view.  Reply With Quote

#### Posting Permissions

• You may not post new threads
• You may not post replies
• You may not post attachments
• You may not edit your posts
•