Round

  • Thread starter Thread starter TomislaW
  • Start date Start date
T

TomislaW

Decimal.Round(num,0) method returns:
4 for 4.4
4 for 4.5
5 for 4.6
I need 5 for 4.5 is there any other way for rounding?
 
TomislaW said:
Decimal.Round(num,0) method returns:
4 for 4.4
4 for 4.5
5 for 4.6
I need 5 for 4.5 is there any other way for rounding?
Click to expand...

Well, you could write a wrapper for Round:

static decimal MyRound (decimal d)
{
decimal ret = Decimal.Round(d);
// Were we on the exact half-way point with
// a rounding down?
if (ret==d-0.5m)
{
return ret+1m;
}
else
{
return ret;
}
}

You should consider what you wish it to do for negative numbers in that
situation, by the way.
 
Decimal.Round(num,0) method returns:
4 for 4.4
4 for 4.5
5 for 4.6
I need 5 for 4.5 is there any other way for rounding?
Click to expand...

public double MyRound( double value )
{
return ( int )( value + 0.5 );
}

n!
 
public double MyRound( double value )
{
return ( int )( value + 0.5 );
}
Click to expand...

Or even:

public double MyRound( double value )
{
return ( int )( value + ( 0.5 * Math.Sign( value ) ) );
}

If you want it to work for negative numbers too, natch.

n!
 
Just to add to the other posts,

I think the problem is that the system actually reads 4.499999999...
something when input 4.5 so the rounding is as far as the computer knows
"correctly" done to 4.0, even though this is not the desired result.
 
Morten Wennevik said:
Just to add to the other posts,

I think the problem is that the system actually reads 4.499999999...
something when input 4.5 so the rounding is as far as the computer knows
"correctly" done to 4.0, even though this is not the desired result.
Click to expand...

No - 4.5 itself is exactly representable, even in a binary floating
point number (although what was actually presented was decimal.Round,
which deals with decimal floating point numbers).

The "problem" is that decimal.Round (and the other Round methods)
perform banker's rounding. From the docs:

<quote>
When d is exactly halfway between two rounded values, the result is the
rounded value that has an even digit in the far right decimal position.
For example, when rounded to two decimals, the value 2.345 becomes 2.34
and the value 2.355 becomes 2.36. This process is known as rounding
toward even, or rounding to nearest.
</quote>
 
Morten said:
Just to add to the other posts,

I think the problem is that the system actually reads 4.499999999...
something when input 4.5 so the rounding is as far as the computer
knows "correctly" done to 4.0, even though this is not the desired
result.
Click to expand...

Nothing like this at all, using decimal it properly understands the correct
value. Actually it's stated very clearly when it rounds up and when down in
the documentation for the method. To cite the docs:

"When d is exactly halfway between two rounded values, the result is the
rounded value that has an even digit in the far right decimal position. For
example, when rounded to two decimals, the value 2.345 becomes 2.34 and the
value 2.355 becomes 2.36. This process is known as rounding toward even, or
rounding to nearest."
--
Tom Porterfield
MS-MVP MCE
http://support.telop.org

Please post all follow-ups to the newsgroup only.
 
My bad, the doc does indeed say exactly that. I read that page, but
somehow I misread 2.345-> 2.35 and thought nothing of it.

But wasn't something similar being discussed a few months ago?
I remember that thread saying something about x.5 being stored as
0.499999999999917354246 or something.
 
Morten Wennevik said:
My bad, the doc does indeed say exactly that. I read that page, but
somehow I misread 2.345-> 2.35 and thought nothing of it.

But wasn't something similar being discussed a few months ago?
I remember that thread saying something about x.5 being stored as
0.499999999999917354246 or something.
Click to expand...

Probably more like x.15 being stored as x.14999999 etc. Yes, that's
true - but I believe that double.Round actually has some interesting
logic in it to detect that kind of situation - if the stored value of
the double is the closest one available to the half-way point (whatever
that point is), it does whatever it should do for that half-way point.

This means that if you've actually got an *accurate* value which is one
side or other of the half-way point, you could get the "wrong" result -
but in general it's probably the best compromise in a situation where
you can't physically store the half-way point in many cases.

See http://groups.google.com/groups?selm=MPG.19bffc1676dbf94298a492
@news.microsoft.com

(aka http://tinyurl.com/ytbyz) for a sample.
 
Morten,
A Decimal isn't stored as floating point though. It is based on scaled
integers so all of them have an exact representation.
Ron Allen
 
Ron Allen said:
A Decimal isn't stored as floating point though. It is based on scaled
integers so all of them have an exact representation.
Click to expand...

To be strictly accurate, it *is* stored as a floating point number -
but it's a floating *decimal* point rather than a floating *binary*
point.
 
Back
Top