Round-to-even 131.575 results in an odd number instead of even

Question

Consider the following code sample:

var tests = new List<double> { 131.505, 131.515, 131.525, 131.535, 131.545, 131.555, 131.565, 131.575, 131.585, 131.595 };
foreach (double n in tests)
{
    Console.WriteLine("{0} => {1}", n, Math.Round(n, 2, MidpointRounding.ToEven));
}

And its output:

131.505 => 131.5
131.515 => 131.51 <- wt*
131.525 => 131.52
131.535 => 131.54
131.545 => 131.54
131.555 => 131.56
131.565 => 131.56
131.575 => 131.57 <- wt*
131.585 => 131.58
131.595 => 131.6

I was expecting:

131.515 => 131.52
131.575 => 131.58

Why does MidpointRounding.ToEven algorithm produce a number that has an odd number at the end; and is there something I could do to fix this?

Background: I am passing the same numbers to PHP round($n, 2, PHP_ROUND_HALF_EVEN) function. The objective is to have both scripts produce same results.

I would appreciate an explanation of what is going on behind the scenes in this particular example instead of a canned "because floating point math is broken" response. I would like to know why PHP is able to produce the expected results but .NET is not? I would like to know if .NET's floating point is broken instead of floating point itself.

Answer 1

Multiple roundings occur when working with floating-point numbers.

In the code you show, the source text 131.515 is converted from a decimal numeral to a double value. Since 131.515 cannot be represented exactly in double, the nearest representable value is produced. This is 131.5149999999999863575794734060764312744140625.

Thus, when Math.round is called, it is given the value 131.5149999999999863575794734060764312744140625. As this is less than 131.515, it is rounded to 131.51.

As Mark Dickinson noted in a comment, Math.Round is itself an imperfect implementation and contains internal rounding errors. For the source text 131.525, the conversion to double produces 131.525000000000005684341886080801486968994140625. Rounding this to two decimal digits after the decimal point ought to produce 131.53. However, Math.Round apparently computes the result by first multiplying by 100. Since the mathematical result of multiplying by 100 is not exactly representable, it is rounded to the nearest representable value, which is 13152.5. Then rounding this to integer with the round-to-nearest-ties-to-even rule produces 13152. Then dividing that and converting it to decimal produces “131.52”.

So we cannot expect Math.round to produce correct results.