Math.Round issue


I want to round in addition with 2 decimal places some numbers
For example the number 68.225 → 68.23

I have used this function:
Math.Round(double.Parse(“68.225”), 2, MidpointRounding.AwayFromZero)
The result is 68.22 and not 68.23.
How exactly works MidpointRounding.AwayFromZero because I cannot get it…?



I guess this is what you need to look at

There in the same link that you gave

nearest even is 2 in your case


No, should be the number which is far away from zero.
In my case:

.225 → .23 is more away from zero than .22


My Bad…You are right…I was assuming even…Pardon me.

But I see a strange behaviour here becasue only for .225 the round off is going wrong always …leaving that number any other round off is proper

Yes that does look strange


the precision will trigger the behavior

XX.225 with a round of 2 digits will come in this case to

if the next digit is 5, which is the midpoint between two possible results, and all remaining digits are zero or there are no remaining digits, the nearest number is ambiguous

so there is no more close / more far and we see the cutoff / round down .225 → .22




With a crosscheck on:

Docu reference to the level of Target Framework Legacy -
Framework 4.6.1

Yes but this is the idea to use AwayFromZero to take the decision in which direction will go, to .22 or to .23

Math.Round(68.225, 2) is the same thing with Math.Round(68.225, 2, MidpointRounding.AwayFromZero) and is not ok in my opinion because when I specify AwayFromZero I expect to round in addition.

Perhaps, I still don’t get it but how can I obtain .23 starting with .225?

we had updated / added some additional docu references after posting the first version maybe it was overseen

Kindly note:

I will test this one but there is a solution to obtain directly a Double without conversion from that string to Double (Double.Parse(68.225.ToString(“F2”))) ?

As a retake we do see the behavior on decimals as


visualized in another way:

I will set as solution your last comment.
I have one more question.
From what I have read I understand that the pattern .XX5 can generate this problem but why cases like .215 or .235 are working as expected?


We assume it is about internal precisions


This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.