Math.Round issue

Help Something Else
1

Hello,

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…?

Thanks,
Vlad

2

@VladTof

I guess this is what you need to look at

image
image937×296 25.1 KB

There in the same link that you gave

nearest even is 2 in your case

chees

3

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

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

4

@VladTof

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

image
image413×751 21.6 KB

Yes that does look strange

cheers

5

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

grafik
grafik909×446 31 KB

grafik

AwayFrom
grafik

ToEven
grafik

With a crosscheck on:
grafik

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

6

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?

7

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

Kindly note:

8

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”))) ?

9

As a retake we do see the behavior on decimals as

grafik

visualized in another way:
grafik

1 Like
10

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?

11

grafik

We assume it is about internal precisions

grafik

12

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