Math.Round fails on 0.50 value

[TechnVision]

Description

As title says Math.Round fails to round 0.50 values be it decimal or double data typed, it rounds these values but returns lower values rather than it should add value 1.

For Ex. if I have to round 99.50 and put Math.Round around it then it will return 99 whereas it should return 100.

Reason: in Excel and in SQL server too its returned 100.

Reproduction Steps

Math.Round(99.50M, 0) // 100 is expected.
Math.Round(99.49M, 0) // 99 is expected and is Okey.
Math.Round(99.51M, 0) // 10 is expected and is Okey.

Expected behavior

Math.Round(99.50M, 0) // 100 is expected.

Actual behavior

Math.Round(99.50M, 0) // 99 is return

Regression?

No response

Known Workarounds

having to write logic for exact 0.50 values while rounding values

Configuration

VS22 Community version along side .Net7, on Win11

Other information

No response

Tagging subscribers to this area: @dotnet/area-system-numerics
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

As title says Math.Round fails to round 0.50 values be it decimal or double data typed, it rounds these values but returns lower values rather than it should add value 1.

For Ex. if I have to round 99.50 and put Math.Round around it then it will return 99 whereas it should return 100.

Reason: in Excel and in SQL server too its returned 100.

Reproduction Steps

Math.Round(99.50M, 0) // 100 is expected.
Math.Round(99.49M, 0) // 99 is expected and is Okey.
Math.Round(99.51M, 0) // 10 is expected and is Okey.

Expected behavior

Math.Round(99.50M, 0) // 100 is expected.

Actual behavior

Math.Round(99.50M, 0) // 99 is return

Regression?

No response

Known Workarounds

having to write logic for exact 0.50 values while rounding values

Configuration

VS22 Community version along side .Net7, on Win11

Other information

No response

Author:	TechnVision
Assignees:	-
Labels:	area-System.Numerics, untriaged
Milestone:	-

[KeterSCP]

The example you provided correctly rounds 99.50 to 100

[EgorBo]

https://learn.microsoft.com/en-us/dotnet/api/system.math.round?view=net-7.0#system-math-round(system-decimal)

Math.Round(decimal) uses MidpointRounding.ToEven rounding mode by default, you can use an overload that accepts custom rounding mode and pass MidpointRounding.AwayFromZero.

[TechnVision]

@KeterSCP

[KeterSCP]

@TechnVision that's not the code you shared in your reproduction example - there you have 99.50.

As mentioned above by @EgorBo, in .NET default rounding is performed to the nearest even value. If you want another strategy, you should specify this explicitly by passing MidpointRounding parameter

[SmartmanApps]

I'm a Maths teacher. If the default behaviour is to "round" off 0.5 to the nearest even number then the default behaviour is against the rules of Maths and is wrong. I imagine that's why the issue was raised (there are other issues with Maths at MS which I'd like to have addressed, but don't know who to direct it to - apparently nobody at all there knows how to expand brackets). 0.5 should ALWAYS be rounded up, that is the rule in Maths. If a user has entered 0.5, then that could've already been rounded off from something like 0.51243217352, but now .NET is randomly "rounding" that down - that is in fact truncation, not rounding, and no rounding function should have that behaviour, only truncating functions. Even 8.500000000000000000000 should be rounded up for this precise reason. You shouldn't presume to know the accuracy of the entered number, just follow the rules of Maths.

[tannergooding]

If the default behaviour is to "round" off 0.5 to the nearest even number then the default behaviour is against the rules of Maths and is wrong

Wikipedia has a nice section explaining this in more detail and why it is important: https://en.wikipedia.org/wiki/Rounding#Rounding_half_to_even

Mathematics has many different rules, scenarios, and considerations and this is carefully considered and designed to provide the greatest default accuracy given the constraints and limitations of the systems we have to work with.

It is likewise not specific to Microsoft. It is the default behavior for most major programming languages and computer hardware around the world. Designed by other mathematicians and statisticians who are experts in their field and have done years of research, collaboration, and peer review on the subject.

[tannergooding]

Ultimately, we are not working with math as you would on paper. We do not have the flexibility of the human brain, we do not have infinite precision and the ability to represent data arbitrarily.

We have a finite set of bits that can represent a finite amount of data. That data is itself representing something which might be infinitely precise or which may require infinite precision due to it being irrational.

Computers then must account for this to avoid introducing greater than necessary error, just as you would when using mathematics in most practical fields, such as engineering or architecture. There is also a level of tolerance given to account for fluctuations, imprecisions, and other error that might be introduced.

[SmartmanApps]

Wikipedia has a nice section explaining this in more detail and why it is important

Wikipedia doesn't know how to expand brackets either (nor how Terms work), so there's that.

Designed by other mathematicians and statisticians who are experts in their field

Can you cite any Mathematicians who have said this? All I see is a reference to IEEE, which isn't a Mathematical body. It looks to me like, just as it is with expanding brackets, these systems have been written without checking with actual Mathematicians.

[tannergooding]

It doesn't apply to only IEEE, as covered by the Wikipedia page it's also known as (among other names):

convergent rounding, statistician's rounding, Dutch rounding, Gaussian rounding, odd–even rounding, or bankers' rounding.

If you'd like more information on why IEEE 754 went the way it did, I'd suggest you download the specification to see a list of its own citations and people who worked on it. Both in the most recent and the overall historical specifications from 1985 and 2008.

Regardless, however, this is never going to change for .NET. It won't change for C, Rust, Java, Python 3, Go, Swift, etc. It likewise won't change the default behavior in hardware for CPUs (x86, x64, Arm32, Arm64, RISC-V, etc) nor will it change it in GPUs and so on.

This is how computers work. It is the industry standard. It is done for good reason and a person not agreeing with the behavior does not make that behavior incorrect nor does it negate the 50+ year history and general consensus on being correct.

If you don't like it, we have APIs (such as Math.Round) that will allow you to customize the behavior based on your exact needs. The same is true in most other languages and they often provide similar functionality to deviate from the standard behavior of round ties to even.

[SmartmanApps]

It doesn't apply to only IEEE, as covered by the Wikipedia page it's also known as (among other names):

convergent rounding, statistician's rounding, Dutch rounding, Gaussian rounding, odd–even rounding, or bankers' rounding.

None of which had any references (only IEEE did), and I can tell you as a Statistician I've never heard of Statistician's rounding. Did you know the Wikipedia page on "implicit multiplication" never mentions Terms or The Distributive Law even once?

a person not agreeing...does not make that behavior incorrect

I'm not "a person" - I'm a Maths teacher, with Maths textbooks which specify why that behaviour is wrong mathematically.

general consensus on being correct

The general consensus has led to a situation where literally only 1 e-calculator (MathGPT) correctly expands brackets - literally every other e-calculator (including every MS product which does calculations, like Excel) incorrectly interpret bracketed terms (which leads to people saying "But the Windows calculator says...", and then I have to explain why the Windows calculator is wrong. Welcome to why this has got my back up - I'm wondering how many other places MS has implemented wrong Maths).

[CyrusNajmabadi]

The onus is not on us to satisfy you. It's on you to put forth a good enough case to change the literal industry standard.

[filipnavara]

@SmartmanApps You being unaware of other rounding algorithms doesn't make them wrong or invalid. They exist for a reason. One of the reasons being accumulation of error which happens to be extremely relevant when dealing with floating point math which operates on base-2 and not base-10.

Likewise, the order of operations is not as universal as you may think. While some countries teach PEMDAS, others teach BEDMAS, BIDMAS, or others. They don't necessarily agree on priorities of certain operations such as implicit multiplication. There are expressions which work universally across most of these systems provided you use explicit parentheses to disambiguate. Similarly, if you want to disambiguate which rounding algorithm you want to use, you have the choice.