Rounding double

[md]

Hi

Does any body know, how to round a double value with a specific number
of digits after the decimal points?

A function like this:

RoundMyDouble (double &value, short numberOfPrecisions)

It then updates the value with numberOfPrecisions after the decimal
point.

Any help is appreciated.

Thanks.
md

[Keith Thompson]

James Kuyper <ja*********@verizon.netwrites:

Bart wrote:
...

>Not many posting here seem to believe there are real and practical
reasons for rounding values to so many decimals (or rounding to a
nearest fraction, a related problem).

Incorrect. What I believe is that the real and practical reasons tend
to fall into two categories:

a) Conversion of floating point numbers to digit strings, usually for
output.

b) Calculations that should, properly, be carried out in fixed-point
arithmetic. In the absence of direct language support for fixed-point,
it should be emulated by the programmer using, for instance, an
integer to represent 1000 times the actual value, if that value is to
be stored with 3 digits after the decimal place. All of the example
you gave should fall into this second category.

[...]

Yes, there are good reasons for wanting to round a numeric value to a
specified number of decimal places, but neither example you provided
(nor any other reasonable example I can think of) calls for storing
the resulting rounded value in a double.

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Bart]

On Nov 27, 7:11 am, Richard Heathfield <[e-mail]:

There are many reasons why this kind of rounding is useful in the real
world, often to deal with noise reduction.

We don't call that "rounding", though. We call it "approximating". Nobody
denies its utility.

I think Keith Thompson and one or two others were.

>But rounding it ain't.

I'm intrigued, why are you so prejudiced about poor old round(x)
function for reasons that could be applied to nearly anything, like
(slightly contrived) a reciprocal(x) function for example? In fact in
seems Divide is the real culprit because often you don't get exactly
what it says on the box.

Bart

[Richard Heathfield]

Bart said:

On Nov 27, 7:11 am, Richard Heathfield <[e-mail]:

There are many reasons why this kind of rounding is useful in the real
world, often to deal with noise reduction.

We don't call that "rounding", though. We call it "approximating".
Nobody denies its utility.

I think Keith Thompson and one or two others were.

>>But rounding it ain't.

I'm intrigued, why are you so prejudiced about poor old round(x)
function for reasons that could be applied to nearly anything, like
(slightly contrived) a reciprocal(x) function for example?

I'm not sure that "prejudiced" is the right word. I don't /use/ it, but
that's only for the same reason that I don't use any C99 features in code
intended to be portable. But round() doesn't actually round to a given
number of decimal places (or rather, it does, provided that the number of
decimal places you want is zero!).

If you try to use it to round 0.33 to one decimal place, e.g. like this:

f = round(f * 10) / 10;

then you'll get 0.30000000000000000001 or 0.29999999999999998 or something
like that. What you won't get is *precisely* 0.3 in f.

In fact in
seems Divide is the real culprit because often you don't get exactly
what it says on the box.

Whatever the culprit, the crime remains - you can't (in the general case)
store an arbitrary value in a double to precisely n decimal places, for
any value of n 0. (You *can* store particular values, of course: 0.5,
0.75, and so on.)

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[James Kuyper]

Richard Heathfield wrote:

Bart said:

....

>I'm intrigued, why are you so prejudiced about poor old round(x)
function for reasons that could be applied to nearly anything, like
(slightly contrived) a reciprocal(x) function for example?

I'm not sure that "prejudiced" is the right word. I don't /use/ it, but
that's only for the same reason that I don't use any C99 features in code
intended to be portable. But round() doesn't actually round to a given
number of decimal places (or rather, it does, provided that the number of
decimal places you want is zero!).

I suspect that he was not talking about the C99 round(); it sounded more
like he was unaware of it's existence. round() can calculate it's result
exactly, at least for it's typical argument values.

I think he using "round()" as a name for the kind of function we've been
talking about in this thread. It takes a double value, and an integer
number of digits, and returns the best possible approximation to the
provided value rounded to the specified number of digits after the
decimal place. For most typical argument values this function cannot
return exactly the mathematical value we would like it to return. In
that regard, it is no different from most other operations on floating
point values, or most other functions taking floating point arguments.

If you try to use it to round 0.33 to one decimal place, e.g. like this:

f = round(f * 10) / 10;

then you'll get 0.30000000000000000001 or 0.29999999999999998 or something
like that. What you won't get is *precisely* 0.3 in f.

For the same reason, reciprocal(5.0) can't give you precisely 0.2. So?
Why is one inaccuracy acceptable, and the other is not? Or are you
suggesting that they're both unacceptable?

[Richard Heathfield]

James Kuyper said:

Richard Heathfield wrote:

<snip>

>If you try to use it to round 0.33 to one decimal place, e.g. like this:

f = round(f * 10) / 10;

then you'll get 0.30000000000000000001 or 0.29999999999999998 or
something like that. What you won't get is *precisely* 0.3 in f.

For the same reason, reciprocal(5.0) can't give you precisely 0.2. So?
Why is one inaccuracy acceptable, and the other is not? Or are you
suggesting that they're both unacceptable?

This was well answered elseperson elsethread. Let me see if I can find it.

Ah, here we go: Message-ID: <fi**********@aioe.org>

in which Keith writes:

"But there's a fundamental difference between sqrt() and a function
that purports to round a floating-point value to a specified number
of decimal places.

"For the sqrt() function, obtaining a close approximation to the
mathematical result is obviously a useful thing to do. There are
some contexts in which you might want to throw up your hands and
say "Sorry, it's not possible to compute sqrt(2.0) exactly" -- but
obtaining a close approximation is both useful and expected.

"For the rounding function, sure, you could write a function that,
given arguments (3.14159, 2) would return the closest floating-point
approximation of the mathematical value 3.14. But it's not at all
clear either that this would be useful, or that it's really what the
original poster wants."

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Bart]

On Nov 27, 2:33 pm, Richard Heathfield <[e-mail]:

James Kuyper said:

For the same reason, reciprocal(5.0) can't give you precisely 0.2. So?

This was well answered elseperson elsethread. Let me see if I can find it.
in which Keith writes:

"But there's a fundamental difference between sqrt() and a function
that purports to round a floating-point value to a specified number
of decimal places.

So, the thing about rounddouble(x,n) is that it always gives an exact
result in decimal arithmetic, compared with reciprocal(x) (sometimes
exact) or sqrt(x) (rarely exact)?

Due to dividing by 10^n which is no problem in decimal but causes
grief in binary?

OK. But back in the practical world, it can still be useful to class a
rounddouble(x) function with sqrt, reciprocal and the like provided
the limitations are known.

Bart.

[Richard Heathfield]

Bart said:

<snip>

OK. But back in the practical world,

I rarely leave it, which is why I think it's so important to get things
right.

it can still be useful to class a
rounddouble(x) function with sqrt, reciprocal and the like provided
the limitations are known.

Of course it can be useful, and nobody denies this - provided, as you say,
the limitations are known. That is why I have laid such stress on pointing
out the limitations (which, it seemed to me, the phrasing of the OP's
question suggested that he didn't know).

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999