Math.Round(value, digits, mode) does not return the correct result

[tannergooding]

The Math.Round(value, digits, mode) code returns a close, but not correct result most of the time.

The root problem is that the algorithm tries to follow normal mathematical rules to produce the result. However, due to the variable precision in IEEE floating-point numbers, this ultimately causes it to produce a close, but generally incorrect result most of the time and causes it to not accept inputs above a certain range. For example, you can't round double.MaxValue and the larger the input is, the more inaccurate the rounding will be.

These functions should be rewritten to be IEEE compliant and to accept any valid finite floating-point input.

[tannergooding]

An example of where this fails is: Math.Round(655.924999999999954525264911353588104248046875, 2, MidpointRounding.AwayFromZero);

The nearest representable value with 2 digits is: 655.91999999999996 (which is the nearest representable value for 655.92 printed with 17 digits of precision), which is 0.004999999999994525264911353588104248046875 away. The next highest representable value with two digits is 655.92999999999995 (which is the nearest representable value for 655.93 printed with 17 digits of precision), which is 0.004999999999995474735088646411895751953125 away.

For this case, the Math.Round code is scaling the input by 100 and getting exactly 65592.5, this ends up losing thinking the original value is a midpoint value (it is not, the actual value is just below a midpoint) and rounding away from zero.

[tannergooding]

Math.Truncate works exactly as intended. It is not a rounding function and instead just truncates all bits, always. This means 3.9 is by design returning 3.

I need to dig up the notes on MidpointRounding.ToNegativeInfinity, ToPositiveInfinity, and ToZero` as I remember there being discussion around there behavior differing.