Why does Convert.ToInt32() round to the nearest even number, instead of nearest whole number? [closed]

Answer 1

_{The History section of the Wikipedia entry for Rounding has some statements about the role of "round to even" in computing. Interestingly, it appears "Bankers Rounding" has little evidence to state it was official in any sense of the word, so can only be chalked up as slang terminology.}

It is only "more logical" if you subscribe to that rounding mechanism. Bankers rounding (which is the default in this case) is also perfectly logical.

Imagine if banks rounded up to the nearest penny for every fractional amount, they would make a lot less (lose a lot of, for the cynical) money with the millions upon millions of transactions that are processed daily. OK, so this example is cynical.

Going towards the nearest even number (or odd, but history chose otherwise) means that not every rounding resolution goes up, some can now go down. When you put this to the law of averages, it becomes a fair solution to use when considering who is responsible for paying for the extra half penny.

As for why this was chosen for the framework, this question attempts to address it:

Why does .NET use banker's rounding as default?

Of course, this all harks back to financial days and its applicability to integral numbers could be questioned, but why bother? Accept it, override it if you want to, just understand how it works.

---

For people wondering how to change the default rounding:

If you are providing a non-integer to Convert.ToInt32 you will first actually need to do something like Convert.ToDouble and then Math.Round with the overload to change the rounding logic.

Answer 2

This is exactly why the MidpontRounding overload was added to Math.Round.

Therefore for correct rounding you should use Math.Round rather than Convert.ToInt32.

Answer 3

Without considering the subjective question of whether MidpointRounding.ToEven (Banker's rounding) or MidpointRounding.AwayFromZero would be a better default.

When designing this, Microsoft would have considered the languages .NET was designed to replace.

• VB classic has always used Banker's Rounding by default.

• C / C++ conversions truncate when casting, and has library functions floor() and ceil() in the runtime library - but (AFAIK, may be wrong) no round function.

• Java has a Math.round that in the documentation is described as being equivalent to Math.round(a+0.5). Which is arguably not what most people would expect for negative numbers (-3.5 rounds to -3).

• VB developers may arguably be expected to need more handholding than developers coming from C/C++ or Java.

Hence it seems reasonable that when designing .NET, the class library would provide Floor, Ceiling and Round methods, and that the Round behavior would default to VB's behavior.

It also seems reasonable that Convert.ToInt32() would use the Round method (though I guess a case could be made for Floor, for consistency with casting).

Answer 4

If you want that behaviour you need to use Math.Round and specify MidpointRounding.AwayFromZero.

For example:

int result = (int)Math.Round(4.5, MidpointRounding.AwayFromZero);

Demo: http://ideone.com/ZAbBL

Convert.ToInt32(double) doesn't use Math.Round itself, instead it's implemented in this way (ILSpy):

public static int ToInt32(double value)
{
    if (value >= 0.0)
    {
        if (value < 2147483647.5)
        {
            int num = (int)value;
            double num2 = value - (double)num;
            if (num2 > 0.5 || (num2 == 0.5 && (num & 1) != 0))
            {
                num++;
            }
            return num;
        }
    }
    else
    {
        if (value >= -2147483648.5)
        {
            int num3 = (int)value;
            double num4 = value - (double)num3;
            if (num4 < -0.5 || (num4 == -0.5 && (num3 & 1) != 0))
            {
                num3--;
            }
            return num3;
        }
    }
    throw new OverflowException(Environment.GetResourceString("Overflow_Int32"));
}