Fabulous Adventures In Coding
Eric Lippert is a principal developer on the C# compiler team. Learn more about Eric.
A number of people have pointed out to me over the years that VBScript's Round function is a bit weird. It seems like it should be pretty straightforward -- you pick the integer closest to the number you've got, end of story. But what about, say, 1.5? There are two closest integers. Do you go up or down?
The Round function goes to the nearest integer, and if there are two nearest integers then it goes to the even one. 1.5 rounds to 2, 0.5 rounds to 0.
Why's that? Why not just arbitrarily say that we always round down in this situation? Why round down sometimes and up some other times? There actually is a good reason!
This algorithm is called the Bankers' Rounding algorithm because, unsurprisingly, it's used by bankers. Suppose a data source provides data which is often in exactly split quantities -- half dollars, half cents, half shares, whatever -- but they wish to provide rounded-off quantities. Suppose further that a data consumer is going to derive summary statistics from the rounded data -- an average, say.
Ideally when you are taking an average you want to take an average of the raw data with as much precision as you can get. But in the real world we often have to take averages of data which has lost some precision. In such a situation the Banker's Rounding algorithm produces better results because it does not bias half-quantities consistently down or consistently up. It assumes that on average, an equal number of half-quantities will be rounded up as down, and the errors will cancel out.
If you don't believe me, try it. Generate a random list of numbers that end in 0.5, round them off, and average them. You'll find that Bankers' Rounding gives you closer results to the real average than "always round down" averaging.
The Round, CInt and CLng functions in VBScript all use the Banker's Rounding algorithm.
There are two other VBScript functions which turn floats into integers. The Int function gives you the first integer less than or equal to its input, and the Fix function gives you the first integer closer to zero or equal to its input. These functions do not round to the nearest integer at all, they simply truncate the fractional part.
UPDATE: What about FormatNumber? See this post.
However it works it would be nice if the documentation actually said what method was adopted rather than leaving us to find out the hard way.....
Actually, I think its flawed for certain numbers. I'm embroiled in a row elsewhere, and I'm researching how to do the 'tricky' numbers. Try this
i = 50/111.111
wscript.echo round(i,2) 'should be 0.46
wscript.echo round(i,1) 'should be 0.4
Oops, sorry typo! second one should be .5, as the input is 0.45000045000045
The actual output for the last two is 0.45 and 0.5, and both are correct.
I am very confused why you think this is a bug. Why do you think that it would round to 0.46? Obviously the input is much, much, much closer to 0.45 than 0.46. It would be a pretty perverse implementation of Round which rounded to the one farther away!
0.0451 -> 0.05
0.0450 -> 0.04
Again, I do not understand why this is a question.
0.0451 could be rounded to 0.04 or 0.05. 0.05 is closer. We round to the closest one. It would be stupid to round to the one farther away.
0.0450 could be rounded to 0.04 or 0.05. Neither is closer than the other. We round to the "even" one.
Many thanks for this gem...
I will go with rounding up as i am providing comparisons.
Well worth knowing though...
Thank goodness that the .Net Framework team thought to put in an overload for Math.Round that includes the MidpointRounding.AwayFromZero so we could bypass this ridiculous concept.
Math.Round should represent mathematics principles, not accounting or banking principles. I agree with the commenter above that suggested a BRound function or perhaps a BankersMath.Round or Accounting.Round. In any and all cases, Math.Round should have followed mathematic standards.
In any case, thanks for the description of what is happening and why my Round calls weren't working.
Kathleen Barnes said:
"Doesn't this still introduce a small amount of bias since you round up all the odd values(1,3,5,7,9) and round down the evens(2,4,6,8) and there is one more odd than even?"
yes is can still add bias but not for that reason. while Eric is right that the number of odd and even numbers is equal, what really matters is the distribution of odd and even numbers in *your sample* when doing repeated rounding (or at least what distribution you might expect when choosing how to round). clearly if you are rounding and summing a series of only odd numbers you will see a bias.
there are many more types of rounding with different properties and trade offs as well of course e.g. stochastic rounding
@Dale, it may be called bankers rounding but this is sound maths used in many scientific and engineering uses e.g. DSP not just accounting (essentially its probably the right thing to do unless you know your samples are *not* uniformly distributed). conversely rounding down is one of the easiest things to do but is seldom correct.
Why not make an standardization of this situation?