There's an IEEE floating-point standard which has been incorporated into many computer programming languages, affecting the assigning of floating point numbers (with decimals) to an integer variable. This assignment operation will "round" the floating point number before storing it into the integer. However, if the number ends in .5 it rounds differently for odd/even numbers; for example, 2.5 is stored into the interger as 2, but 3.5 is stored as 4. The IEEE standard attempts to "balance" the effects of rounding by not always rounding up. (I reserve my comments). Another problem is that the IEEE standard also rounds negative numbers differently that positive numbers. These IEEE differences do not comply with common accounting practice regarding rounding. Can you imaging explaining to a CPA that your program rounds even/odd numbers and positive/negative numbers differently? Ok, then what I recommend is: 1) Never assign floating point numbers to integer variables expecting proper rounding, and don't use any built-in functions in your language that claim to do this, like the CINT (Convert to Integer) function in most Basic's. 2) Perform rounding with the following code. Please excuse the Basic code, I haven't written C in 8 years and I'm rusty: N is assumed to be defined as a floating point number. ROUNDED.RESULT = SGN(N) * INT(ABS(N) + .5) The above code takes the following into consideration: * The absolute or ABS assures that the number to work with is positive. * This positive number is rounded by the rounding factor of "+.5". * The integer value INT is taken on the above positive result. * The sign of the original input number is restored by multiplying by the sign or SGN which is 1 for positive, -1 for negative, and 0 for zero. You can provide scaling of the number into the code depending on where the decimal point lies or if it is implied. *****

ok, if you say so. Chi Happens

Actually, Chi, I was looking for opinions. I can't find any documented evidence anywhere of what I've been calling "standard accounting practice" regarding rounding. I even contacted the American Institute of CPA's, and they said they didn't have such a standard. Any ideas?

The standard is IEEE 754. It is one of four methods of rounding discussed (of binary floating point numbers). I don't know how it became applied to accounting. However I have used it in my early programming of financial tables, etc. in the 1980's. Quit using, after we did not need the to the nearest cent accuracy. I think that it may be related to the 5/4 rounding on adding machines. An explanation follows. Exerpted from: http://docs.sun.com/source/817-0932/ncg_goldberg.html#pgfId-682 A P P E N D I X D ------------------ What Every Computer Scientist Should Know About Floating-Point Arithmetic ------------------ Note - This appendix is an edited reprint of the paper What Every Computer Scientist Should Know About Floating-Point Arithmetic, by David Goldberg, published in the March, 1991 issue of Computing Surveys. Copyright 1991, Association for Computing Machinery, Inc., reprinted by permission. ----------------- ... So far, the definition of rounding has not been given. Rounding is straightforward, with the exception of how to round halfway cases; for example, should 12.5 round to 12 or 13? One school of thought divides the 10 digits in half, letting {0, 1, 2, 3, 4} round down, and {5, 6, 7, 8, 9} round up; thus 12.5 would round to 13. This is how rounding works on Digital Equipment Corporation's VAX computers. Another school of thought says that since numbers ending in 5 are halfway between two possible roundings, they should round down half the time and round up the other half. One way of obtaining this 50% behavior to require that the rounded result have its least significant digit be even. Thus 12.5 rounds to 12 rather than 13 because 2 is even. Which of these methods is best, round up or round to even? Reiser and Knuth [1975] offer the following reason for preferring round to even. Theorem 5 Let x and y be floating-point numbers, and define x0 = x, x1 = (x0 y) y, …, xn = (xn-1 y) y. If and are exactly rounded using round to even, then either xn = x for all n or xn = x1 for all n 1. To clarify this result, consider = 10, p = 3 and let x = 1.00, y = -.555. When rounding up, the sequence becomes x0 y = 1.56, x1 = 1.56 .555 = 1.01, x1 y = 1.01 .555 = 1.57, and each successive value of xn increases by .01, until xn = 9.45 (n 845)[9]. Under round to even, xn is always 1.00. This example suggests that when using the round up rule, computations can gradually drift upward, whereas when using round to even the theorem says this cannot happen. Throughout the rest of this paper, round to even will be used. One application of exact rounding occurs in multiple precision arithmetic. There are two basic approaches to higher precision. One approach represents floating-point numbers using a very large significand, which is stored in an array of words, and codes the routines for manipulating these numbers in assembly language. The second approach represents higher precision floating-point numbers as an array of ordinary floating-point numbers, where adding the elements of the array in infinite precision recovers the high precision floating-point number. It is this second approach that will be discussed here. The advantage of using an array of floating-point numbers is that it can be coded portably in a high level language, but it requires exactly rounded arithmetic. The key to multiplication in this system is representing a product xy as a sum, where each summand has the same precision as x and y. This can be done by splitting x and y. Writing x = xh + xl and y = yh + yl, the exact product is xy = xh yh + xh yl + xl yh + xl yl. If x and y have p bit significands, the summands will also have p bit significands provided that xl, xh, yh, yl can be represented using [p/2] bits. When p is even, it is easy to find a splitting. The number x0.x1 … xp - 1 can be written as the sum of x0.x1 … xp/2 - 1 and 0.0 … 0xp/2 … xp - 1. When p is odd, this simple splitting method will not work. An extra bit can, however, be gained by using negative numbers. For example, if = 2, p = 5, and x = .10111, x can be split as xh = .11 and xl = -.00001. There is more than one way to split a number. A splitting method that is easy to compute is due to Dekker [1971], but it requires more than a single guard digit. ...

Wizard-fred, Thanks for your informative response. It seems that all the documented material is about the IEEE standard. Actually, I'm trying to find information about accounting common practice regarding rounding, which differs from the IEEE 754 as follows: 1) Positive numbers whose decimal part is .5 are always rounded up. I consider this to be the common way of rounding. Taxes on any bill will always be rounded up in this manner, as well as interest on your credit card statement. 2) Positive numbers are always rounded to the next positive number, and negative numbers are always rounded to the next negative number. Example: 123.9 is rounded to 124, and -123.9 is rounded to -124. Do you agree that these are common practice? Is so, please help me find some documented evidence. Thanks.