Rounding double

[Marco Manfredini]

Re: Rounding double

Kai-Uwe Bux wrote:

A different interpretation of floating point computations is that an
operation (say multiplication, addition, sqrt, or rounding to a given
number of decimal places) should yield a double (or float or whatever
types are topical in the corresponding newsgroup) that is closest to
the exact mathematical result. If I recall correctly, this is by and
large the position taken by IEEE754.
>
When this (reasonable) interpretation is adopted, the problem of
rounding to a fixed number of decimals is solvable (and it is indeed
not different from any other computational problem). And if you don't
adopt an interpretation like that, floating point arithmetic in
general is "impossible ".

The problem with rounded numbers is that they have to be exact or else
the whole rounding is pointless. Rounding is done, because you want a
number whose relative error is 1) known 2) independent of the
representation and 3) it's operations gives the same result *no matter
what implementation of arithmetic operations you are using, given that
the result remains exact and representable*. If you have a bank account
you will acknowledge this - financial applications often have very
tight specifications on *how exactly* something has to be calculated,
when rounding must be done etc.

That's entirely different from working with trancedental numbers and
such which have no known representation anyway.

And actually, the problem is solvable with floating point. Multiply and
truncate, but omit the division and store the result with the decimal
designator in a struct { double value; int places; }. Voila, an exactly
rounded number. Now define arithmetic ops and go.

--
IYesNo yes=YesNoFactor y.getFactoryIns tance().YES;
yes.getDescript ion().equals(ar ray[0].toUpperCase()) ;

[Bart]

Re: Rounding double

On Nov 23, 10:29 am, Richard Heathfield <r...@see.sig.i nvalidwrote:

on my system. Quite apart from the fact that you are trying to solve an
impossible problem (the problem, remember, is that of rounding the value
of a double to a specified number of decimal places, which simply can't be
done)

Impossible? Rounding a floating point number to N decimals, or for
that matter any other interval such as 1/30, is possible and does have
uses other than simply printing the number.

Of course the result will be approximate because of the nature of
floating point, but will be billions of times more accurate than
doing no rounding because 'it can't be done'.

If I have a measurement X somewhere along a 1m stick (0.0 to 1.0) and
I want to find the nearest 10cm mark to X (eg X is 0.78, the nearest
will be 0.8), then it's clear than I can round 0.78 to 1 decimal (or
1/10) to get 0.8. The result, being stored in floating point binary,
may be out by a billionth of a micron or so. So what? My pencil mark
on the stick will not be that accurate.

The point is such a rounding can be done and has a useful purpose.

Bart

[James Kuyper]

Re: Rounding double

Richard Heathfield wrote:

jacob navia said:
>
<snip>
>

>All trascendental functions, sqrt, pow, whatever. All of them yield
>approximatio ns of their real results.

>
Indeed, because finitely many bits cannot store the results precisely; and
this is why the OP's problem *as stated* has no solution. You are solving
a *different* problem (in a non-portable way).

It is quite possible that the OP was unaware of the fact that the
rounding could not be performed exactly. However, you cannot justify
assuming that he had that misconception just because he failed to
specify that he wanted the best available floating point approximation
to the rounded number. Leaving out the "best available approximation
...." wording in the expectation that it would be inferred by any
reasonable reader is the norm, not the exception, in such specifications.

The OP's follow-up messages have not clarified whether or not he was
aware of that issue when he posted the original message.

[Kai-Uwe Bux]

Re: Rounding double

Richard Heathfield wrote:

jacob navia said:
>
<snip>
>

>All trascendental functions, sqrt, pow, whatever. All of them yield
>approximatio ns of their real results.

>
Indeed, because finitely many bits cannot store the results precisely; and
this is why the OP's problem *as stated* has no solution. You are solving
a *different* problem (in a non-portable way).

Well, telling the OP that his problem is unsolvable "as stated" could be a
good thing. Maybe he then just decides to report back to the customer and
the customer realizes that this was a stupid thing to ask for and everybody
is happy.

Another possible reaction of the OP is to not find that reply very helpful.
Maybe, he even thinks that you did not make an honest effort to interpret
his question correctly. Why would the OP want to know how to do X if a
moments thought tells you that doing X is impossible? Well, maybe he
doesn't know enough about floating point arithmetic to tell. But, maybe the
OP is not that uneducated and just gave an abbreviated description of the
problem (very much like the C standard where it requires that sqrt shall
compute the nonnegative square root of the argument).

When someone asks a question, the goal of interpretation is to figure out
what it is that this someone wants to know. I have the feeling that your
interpretation might fall short of reaching this goal. I do concede,
though, that we do not have much to go on.

It would be great if the OP could provide some more background as to _why_
he wants to round. For instance, it could be that he needs to comply with
accounting rules in his country which may require that certain values be
rounded to n decimals when transcribed from one table into another.
Depending on the purpose, your advice of postponing the problem until
output might be the right one; or it might be that the OP needs to use
decimal arithmetic instead of double to actually solve the hidden problem.


Best

Kai-Uwe Bux

[Richard Heathfield]

Re: Rounding double

Philip Potter said:

Richard Heathfield wrote:

>jacob navia said:
>>

>>Since you provide no information on which compilation options
>>you used, no information on which system you are running, this
>>can't be solved really.

>>
>The compilation options shouldn't matter, but I'll tell you anyway:

>
No, they *do* matter. gcc is not a conforming C89, C95 or C99
implementation with no compilation options. With -ansi -pedantic, it's
quite a good C89 compiler. With -std=c99 -pedantic, it's a half-finished
C99 compiler.
>
I'm sure you know this already.

Yes, it's a fair point. Okay, if I invoke gcc in conforming mode, the code
doesn't compile at all, for a number of reasons. (Clearly, to invoke gcc
in conforming mode means we have to go for C89 or, if you prefer, C90
conformance, since gcc doesn't have a C99 conforming mode.)

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

[jacob navia]

Re: Rounding double

James Kuyper wrote:

Richard Heathfield wrote:

>jacob navia said:
>>
><snip>
>>

>>All trascendental functions, sqrt, pow, whatever. All of them yield
>>approximation s of their real results.

>>
>Indeed, because finitely many bits cannot store the results precisely;
>and this is why the OP's problem *as stated* has no solution. You are
>solving a *different* problem (in a non-portable way).

>
It is quite possible that the OP was unaware of the fact that the
rounding could not be performed exactly. However, you cannot justify
assuming that he had that misconception just because he failed to
specify that he wanted the best available floating point approximation
to the rounded number. Leaving out the "best available approximation
..." wording in the expectation that it would be inferred by any
reasonable reader is the norm, not the exception, in such specifications.
>
The OP's follow-up messages have not clarified whether or not he was
aware of that issue when he posted the original message.
>

In general, 100% exact results using floating point are impossible,
as you know very well.

Then, obviously, anyone asking here for the best rounding to n places
is asking for an approximation.

Suppose we get a question like:

"Please how can I calculate the square root of a number in C"

we all assume that it is about "the best floating point
approximation" and nobody would say "This problem
is impossible to solve as demonstrated by the greeks around
2000 years ago"

Nowhere did the OP say that he wanted 100% accuracy!

Now that Mr Heathfield sees that his position is completely untenable,
he starts modifying the original question, putting more words into the
OP than what he actually said.

I have argued since the beginning that the problem is solvable in
floating point in the usual floating pont manner, i.e. as an
approximation to the true result!

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique

http://www.cs.virginia.edu/~lcc-win32

[Richard Heathfield]

Re: Rounding double

Bart said:

On Nov 23, 10:29 am, Richard Heathfield <r...@see.sig.i nvalidwrote:
>

>on my system. Quite apart from the fact that you are trying to solve an
>impossible problem (the problem, remember, is that of rounding the value
>of a double to a specified number of decimal places, which simply can't
>be done)

>
Impossible? Rounding a floating point number to N decimals, or for
that matter any other interval such as 1/30, is possible and does have
uses other than simply printing the number.

Show me.

>
Of course the result will be approximate

But rounding is an operation that yields an exact result. 0.33, rounded to
one decimal place, is *precisely* 0.3, not 0.2999999999999 98 or
0.3000000000000 01 (no, I didn't count the 9s and 0s - I just held the key
down!). If the result is not exact, it isn't a rounding. It's merely an
approximation to a rounding.

because of the nature of
floating point, but will be billions of times more accurate than
doing no rounding because 'it can't be done'.

Oh, it can be done all right - it's just that it can't be done using
floating point. More precisely, you can't store 0.33 rounded to one
decimal place in a floating point number (unless you use a radix that
makes it possible, in which case there are other numbers you can't store).

If I have a measurement X somewhere along a 1m stick (0.0 to 1.0) and
I want to find the nearest 10cm mark to X (eg X is 0.78, the nearest
will be 0.8), then it's clear than I can round 0.78 to 1 decimal (or
1/10) to get 0.8.

Right.

The result, being stored in floating point binary,
may be out by a billionth of a micron or so. So what? My pencil mark
on the stick will not be that accurate.

Indeed, but the result will still be out.

The point is such a rounding can be done and has a useful purpose.

Yes, it can, but only by adopting a different representation. A double
simply can't cut it.

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

[jacob navia]

Re: Rounding double

Richard Heathfield wrote:

Philip Potter said:
>

>Richard Heathfield wrote:

>>jacob navia said:
>>>
>>>Since you provide no information on which compilation options
>>>you used, no information on which system you are running, this
>>>can't be solved really.
>>The compilation options shouldn't matter, but I'll tell you anyway:

>No, they *do* matter. gcc is not a conforming C89, C95 or C99
>implementati on with no compilation options. With -ansi -pedantic, it's
>quite a good C89 compiler. With -std=c99 -pedantic, it's a half-finished
>C99 compiler.
>>
>I'm sure you know this already.

>
Yes, it's a fair point. Okay, if I invoke gcc in conforming mode, the code
doesn't compile at all, for a number of reasons. (Clearly, to invoke gcc
in conforming mode means we have to go for C89 or, if you prefer, C90
conformance, since gcc doesn't have a C99 conforming mode.)
>

Can you stop all this theater?

Now compile with
gcc -std=c99 jn.c -lm

and tell me the results ok?

And if you do not want it do not compile it and shut up.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique

http://www.cs.virginia.edu/~lcc-win32

[Richard Heathfield]

Re: Rounding double

James Kuyper said:

Richard Heathfield wrote:

>jacob navia said:
>>
><snip>
>>

>>All trascendental functions, sqrt, pow, whatever. All of them yield
>>approximation s of their real results.

>>
>Indeed, because finitely many bits cannot store the results precisely;
>and this is why the OP's problem *as stated* has no solution. You are
>solving a *different* problem (in a non-portable way).

>
It is quite possible that the OP was unaware of the fact that the
rounding could not be performed exactly.

That is my belief, yes.

However, you cannot justify
assuming that he had that misconception just because he failed to
specify that he wanted the best available floating point approximation
to the rounded number.

On the other hand, answering *all* the questions people *don't* ask would
take infinite time. We're not mind readers.

If the OP is happy to take 0.2999999999999 999999999998 as the result of
rounding 0.33 to one decimal place, that's fine - but he has not (yet)
said so.

<snip>

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

[Kai-Uwe Bux]

Re: Rounding double

Marco Manfredini wrote:

Kai-Uwe Bux wrote:
>

>A different interpretation of floating point computations is that an
>operation (say multiplication, addition, sqrt, or rounding to a given
>number of decimal places) should yield a double (or float or whatever
>types are topical in the corresponding newsgroup) that is closest to
>the exact mathematical result. If I recall correctly, this is by and
>large the position taken by IEEE754.
>>
>When this (reasonable) interpretation is adopted, the problem of
>rounding to a fixed number of decimals is solvable (and it is indeed
>not different from any other computational problem). And if you don't
>adopt an interpretation like that, floating point arithmetic in
>general is "impossible ".

>
The problem with rounded numbers is that they have to be exact or else
the whole rounding is pointless.

A rounding rule is a function r : R --R with usually discrete image. The
possible reasons for computing that function vary. Depending on the
reasons, an IEEE754-like rounding function may or may not be fit for a
given purpose.

Rounding is done, because you want a
number whose relative error is 1) known 2) independent of the
representation and 3) it's operations gives the same result *no matter
what implementation of arithmetic operations you are using, given that
the result remains exact and representable*. If you have a bank account
you will acknowledge this - financial applications often have very
tight specifications on *how exactly* something has to be calculated,
when rounding must be done etc.

I am not sure I understand your conditions (2) and (3). However, with regard
to accounting software, you might sometimes get away with an IEEE754-like
rounding function, although I would think that it can be somewhat difficult
to prove that the output is not different from the theoretical output if
rounding was done exactly. However, in principle this is no different from
the analysis of other errors. You know that the rounding function used has
a small error compare to the mathematical rounding, and now you have to
show that this error stays small and does not influence the printed result
(here of course, you have to take into account the rounding that occurs in
printing).

That's entirely different from working with trancedental numbers and
such which have no known representation anyway.

Not as far as the numerical analysis of algorithms is concerned. However, as
a practical matter, it might be much easier to use a decimal_number class
that allows for exact rounding. This way, you are only using the basic
operations recognized by the accounting rules of the land, and you are
guaranteed that floating point arithmetic won't get you in jail.

And actually, the problem is solvable with floating point. Multiply and
truncate, but omit the division and store the result with the decimal
designator in a struct { double value; int places; }. Voila, an exactly
rounded number. Now define arithmetic ops and go.

I would think that that is one way to go about implementing a decimal_number
class.


Best

Kai-Uwe Bux

[Richard Heathfield]

Re: Rounding double

jacob navia said:

<snip>

Nowhere did the OP say that he wanted 100% accuracy!

The OP said (and I'm quoting this for the *third* time): "Does any body
know, how to round a double value with a specific number of digits after
the decimal points?"

Thus, rounding 0.33 to one decimal place should result in a result with
*one* decimal place, not a couple of dozen decimal places.

>
Now that Mr Heathfield sees that his position is completely untenable,

On the contrary, I maintain that my position is not only tenable but the
best position to take on the available evidence.

he starts modifying the original question, putting more words into the
OP than what he actually said.

On the contrary, I have stuck to the original question, and have not read
into it the same unstated assumptions that some others (including you)
have been making.

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

[Philip Potter]

Re: Rounding double

Richard Heathfield wrote:

Philip Potter said:
>

>Richard Heathfield wrote:

>>jacob navia said:
>>>
>>>Since you provide no information on which compilation options
>>>you used, no information on which system you are running, this
>>>can't be solved really.
>>The compilation options shouldn't matter, but I'll tell you anyway:

>No, they *do* matter. gcc is not a conforming C89, C95 or C99
>implementati on with no compilation options. With -ansi -pedantic, it's
>quite a good C89 compiler. With -std=c99 -pedantic, it's a half-finished
>C99 compiler.
>>
>I'm sure you know this already.

>
Yes, it's a fair point. Okay, if I invoke gcc in conforming mode, the code
doesn't compile at all, for a number of reasons. (Clearly, to invoke gcc
in conforming mode means we have to go for C89 or, if you prefer, C90
conformance, since gcc doesn't have a C99 conforming mode.)

So you take a C99 program (for I assume that is what it is since it uses
long long) and compile it with a C89 compiler, and complain when it
doesn't work?

Surely you know better than that?

[Richard Heathfield]

Re: Rounding double

jacob navia said:

Richard Heathfield wrote:

<snip>

>Yes, it's a fair point. Okay, if I invoke gcc in conforming mode, the
>code doesn't compile at all, for a number of reasons. (Clearly, to
>invoke gcc in conforming mode means we have to go for C89 or, if you
>prefer, C90 conformance, since gcc doesn't have a C99 conforming mode.)
>>

>
Can you stop all this theater?

By "theater", presumably you mean my legitimate objections that the code
doesn't work on my system.

>
Now compile with
gcc -std=c99 jn.c -lm

Okay.

and tell me the results ok?

Okay.

cc1: unknown C standard `c99'

So - do you have a *portable* solution or don't you?

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

[Richard Heathfield]

Re: Rounding double

Philip Potter said:

<snip>

So you take a C99 program (for I assume that is what it is since it uses
long long) and compile it with a C89 compiler, and complain when it
doesn't work?

I don't have a C99 compiler. Neither, I would venture to suggest, do you.
If the code requires C99 conformance, that in itself is sufficient to
render the code almost valueless (quite apart from the fact that it
doesn't solve the problem that the OP posed), since almost nobody has a
conforming C99 compiler.

Surely you know better than that?

Almost nobody has a conforming C99 compiler. It is a very good bet indeed
that the OP does not have a conforming C99 compiler. It is therefore very
poor form indeed to post code that relies on C99 features as a proposed
solution to the OP's problem.

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

[jacob navia]

Re: Rounding double

Richard Heathfield wrote:

>
But rounding is an operation that yields an exact result. 0.33, rounded to
one decimal place, is *precisely* 0.3, not 0.2999999999999 98 or
0.3000000000000 01 (no, I didn't count the 9s and 0s - I just held the key
down!). If the result is not exact, it isn't a rounding. It's merely an
approximation to a rounding.
>

>because of the nature of
>floating point, but will be billions of times more accurate than
>doing no rounding because 'it can't be done'.

>
Oh, it can be done all right - it's just that it can't be done using
floating point. More precisely, you can't store 0.33 rounded to one
decimal place in a floating point number (unless you use a radix that
makes it possible, in which case there are other numbers you can't store).
>

We all know that Heathfield. O.3 is not representable,
so what?

We use the best approximation to it!

Pi is not representable nor "e" (the base of natural logarithms).

So WHAT?

We use the best approximation.

0.1 is not representable. SO WHAT?
We use the best approximation.

AND SO ON.

You go on and on repeating the same thing:

"Floating point numbers are an approximation, not the true result".

We all know that. That doesn't mean that approximations to the true
result are impossible, and that we can't give the OP an approximation
to the true result!

>

>If I have a measurement X somewhere along a 1m stick (0.0 to 1.0) and
>I want to find the nearest 10cm mark to X (eg X is 0.78, the nearest
>will be 0.8), then it's clear than I can round 0.78 to 1 decimal (or
>1/10) to get 0.8.

>
Right.
>

>The result, being stored in floating point binary,
>may be out by a billionth of a micron or so. So what? My pencil mark
>on the stick will not be that accurate.

>
Indeed, but the result will still be out.
>

That is floating point! It is intrinsic to the nature of floating
point, and all your argumentation is just a boring remake
of the "floating point is always an approximation" mantra.

>The point is such a rounding can be done and has a useful purpose.

>
Yes, it can, but only by adopting a different representation. A double
simply can't cut it.
>

A double can have a precision of e-14 or e-15.
This allows to give the radius of the earth to a precision of a few
nanometers!


--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique

http://www.cs.virginia.edu/~lcc-win32