Rounding double

[Richard Heathfield]

Re: Rounding double

jacob navia said:

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.300000000000 001 (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?

So the original problem is insoluble, and another approach must be found,
such as the approach I suggested in my very first reply. Pretending that
0.3 *is* representable in a double (without switching to a radix that
makes other numbers unrepresentable ) is silly.

<snip>

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

Quite so. This is indeed the whole point.

<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

[jacob navia]

Re: Rounding double

Richard Heathfield wrote:

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

Look that result is
-0.0000000000000 000000000002 or 2e-25 different from the true
result. At this precision you can measure the radius of the earth
to the radius of an electron or more!

Floating point is floating point, we all know that Heathfield.
But the correct answer for this questions is surely a function
similar to the one I am proposing.

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

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

[Marco Manfredini]

Re: Rounding double

jacob navia wrote:

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

In general 100% exact results using floating point are possible,
provided you do not perform operations which return inexact results.
1.0 + 1.0 has an exact representation, and so has 1234.75 and you may
even "round" a partial result or parameter (i.e. declare it exact) and
design your computation that no inexact results are created. This is
useful if you need a reliable error estimate on you result. IEEE 754
even allows you to arm a trap if an inexact result occurs during a
computation.

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

[jacob navia]

Re: Rounding double

Richard Heathfield wrote:

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.

Then you can't compile C code according to the standard.
That's bad for you, specially since a better version of gcc
would compile this code without any problems.

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

gcc conforms very well, IBM's compiler also, and many other compilers
like Comeau, and Intel. Other compiler like lcc-win are advanced
in their complicance. You just hate any progress in C and want to
come back more than 15 years back to the times of C89!

>Surely you know better than that?

>
Almost nobody has a conforming C99 compiler.

This is not true and you know it.

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

C99 is the current standard, and I hate this people that always have
in their mouths "Standard C" and then do not mean with that the
standard as accepted by the standards body!


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

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

[jacob navia]

Re: Rounding double

Marco Manfredini wrote:

jacob navia wrote:
>

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

>
In general 100% exact results using floating point are possible,
provided you do not perform operations which return inexact results.

Yeah. Division for instance!

1.0 + 1.0 has an exact representation, and so has 1234.75 and you may
even "round" a partial result or parameter (i.e. declare it exact) and
design your computation that no inexact results are created. This is
useful if you need a reliable error estimate on you result. IEEE 754
even allows you to arm a trap if an inexact result occurs during a
computation.
>

Have you ever tried to trap on "inexact"?

You can't do any square roots, or any mathematical work!

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

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

[James Kuyper]

Re: Rounding double

Richard Heathfield wrote:

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.

If the only features of C99 that it uses are features that are widely
supported by compilers in their C99 modes, then the fact that those
modes are not fully conforming is not sufficient to render the code
valueless.

[jacob navia]

Re: Rounding double

James Kuyper wrote:

Richard Heathfield wrote:

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

>
>
If the only features of C99 that it uses are features that are widely
supported by compilers in their C99 modes, then the fact that those
modes are not fully conforming is not sufficient to render the code
valueless.

C99 *IS* the standard as defined by ISO/ANSI. If we say that this group
discussed "standard c" as repeated by this "regulars" over and over
let's stay within STANDARD C!

I have been working like 10 years in the implementation of a C99
compliant compiler and I think it is time to use that!

And if it doesn't run with Mr Heathfield machine/system/compiler I do
not care.

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

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

[James Kuyper]

Re: Rounding double

Richard Heathfield wrote:

James Kuyper said:

....

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

No, but we should be able to read ordinary English (and technical
English) and interpret it in conventional fashion as implying, as it
normally does, a great many unstated assumptions. Stating all applicable
assumptions would also take infinite time. Even explicitly stating only
the most important assumptions that are conventionally left unstated
would make the questions unreadable.

[Marco Manfredini]

Re: Rounding double

jacob navia wrote:

Marco Manfredini wrote:

>jacob navia wrote:
>>

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

>>
>In general 100% exact results using floating point are possible,
>provided you do not perform operations which return inexact results.

>
Yeah. Division for instance!

Most signal processing algorithms are designed to work without divisions
for instance. Division by 2 occurs, but this is also exact unless you
lose the lsb in de-normalization.

>

>1.0 + 1.0 has an exact representation, and so has 1234.75 and you may
>even "round" a partial result or parameter (i.e. declare it exact)
>and design your computation that no inexact results are created. This
>is useful if you need a reliable error estimate on you result. IEEE
>754 even allows you to arm a trap if an inexact result occurs during
>a computation.
>>

>
Have you ever tried to trap on "inexact"?
>
You can't do any square roots, or any mathematical work!

And you didn't understand the argument. You can prepare a computation by
isolating the inexact part, estimate the error and continue with the
exact part, guarded by the trap. At the end you can prove that your
result is exact to 10^-9, which is much better than "looks plausible to
me if I printf it, I think"

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

[jacob navia]

Re: Rounding double

jacob navia wrote:

I have been working like 10 years in the implementation of a C99
compliant compiler and I think it is time to use that!

Replace 10 by "many"...

Incredible the kind of nonsense I say when I get angry.

Excuse me.

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

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

[vippstar@gmail.com]

Re: Rounding double

On Nov 23, 3:36 pm, jacob navia <ja...@nospam.c omwrote:

jacob navia wrote:

I have been working like 10 years in the implementation of a C99
compliant compiler and I think it is time to use that!

>
Replace 10 by "many"...
>
Incredible the kind of nonsense I say when I get angry.

The trick is not to improve your wording when angry, but to avoid
getting angry.

I believe no more posts need to be done, for it will lead to more
inaccuracies and 'flame wars' from Mr Heathfield, Mr Navia or some
other regular.
I find it rather amusing that c.l.c regulars have been arguing for
something so trivial in nature for 150 posts now.

[Flash Gordon]

Re: Rounding double

jacob navia wrote, On 23/11/07 11:34:

Kai-Uwe Bux wrote:

>Richard Heathfield wrote:
>>

>>jacob navia said:
>>>
>><snip>
>>>
>>>2: As you can see, my solution works in your machine. Either RH is not
>>>telling the truth (unlikely) or he is using some minor error in the
>>>code to trip about.
>>If your code has an error, however minor, then it is broken, in which
>>case
>>I suggest you post a fixed version. The version you posted *does not
>>work*
>>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), you are trying to solve it in a way that produces bizarrely
>>incorrect results on at least one system.

>>
>Hm. I wonder if this might be a matter of interpreting the problem.
>>
>The C standard says about sqrt() that it computed the nonnegative square
>root. C++ inherits this requirement. If your interpretation of the
>rounding
>problem is correct and if we transfer it to the other arithmetic
>operations, then there can be no conforming implementations . In fact,
>even
>elementary school arithmetic (+,-,*,/) cannot be done correctly under
>that
>interpretation . However, that interpretation of the specs is not the only
>possible.

Actually, there can be *lots* of conforming implementations if N1256 is
to be believed, since section 5.2.4.2.2 paragraph 5 says:
| The accuracy of the floating-point operations (+, -, *, /) and of the
| library functions in <math.hand <complex.htha t return
| floating-point results is implementation-defined, as is the accuracy of
| the conversion between floating-point internal representations and
| string representations performed by the library functions in
| <stdio.h>, <stdlib.h>, and <wchar.h>. The implementation may state
| that the accuracy is unknown.

So it is explicitly allowed to be less than 100% accurate.

I am arguing precisely this since the beginning of this thread.
All trascendental functions, sqrt, pow, whatever. All of them yield
approximations of their real results.

Yes, and the specification allows for this, the OPs specification on the
other hand does not.

The solution I proposed is surely not the best one but it is a first
try after a summary discussion here.

It also does not meet the stated requirements. That the requirements are
impossible means you need to explain why they are impossible (and this
has been explained) not provide code that fails to meet the requirements
without stating this.

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

>
EXACTLY.

It is not the position taken by the C standard, which just required that
the accuracy be defined by the implementation.

>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
>interpretati on
>like that, floating point arithmetic in general is "impossible ".

>
This is exactly my position.

It fails to allow for the empirical evidence that most people asking for
things like this are not aware that they are not possible, so they need
to have this explained so they can work out how to deal with the problem.

As I pointed out else-thread, the OP might be adding up millions of such
numbers and be required to produce a final result within a given
accuracy and your method would not guarantee this.
--
Flash Gordon

[Philip Potter]

Re: Rounding double

Richard Heathfield wrote:

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.

So? If you don't have a C compiler, you don't try a FORTRAN compiler
instead to see if it works.

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.

I know you dislike many features of C99 and also like to talk about the
lack of uptake of C99; however that is not a valid reason to compile
code which uses "long long" under C89 and complain that it doesn't work.
Of course it doesn't work, it's not C89 code!

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

If that is your problem with Jacob's program then say so. The fact that
Jacob's code is broken in C89 might be something you personally dislike,
but if it works in C99 it is perfectly topical regardless of the number
of working C99 distributions in existence.

[jacob navia]

Re: Rounding double

vippstar@gmail. com wrote:

On Nov 23, 3:36 pm, jacob navia <ja...@nospam.c omwrote:

>jacob navia wrote:

>>I have been working like 10 years in the implementation of a C99
>>compliant compiler and I think it is time to use that!

>Replace 10 by "many"...
>>
>Incredible the kind of nonsense I say when I get angry.

The trick is not to improve your wording when angry, but to avoid
getting angry.
>
I believe no more posts need to be done, for it will lead to more
inaccuracies and 'flame wars' from Mr Heathfield, Mr Navia or some
other regular.
I find it rather amusing that c.l.c regulars have been arguing for
something so trivial in nature for 150 posts now.

That is easy to say but...

What is YOUR opinion in this matter?

(Hereby I promise not to start any flame war with your
answer )


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

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

[Bart]

Re: Rounding double

On Nov 23, 12:41 pm, Richard Heathfield <r...@see.sig.i nvalidwrote:

Bart said:
>

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.

Maybe the problem is the precise meaning of 'rounding'. Call it
nearest to 1/1000 or whatever and then the inaccuracies can be
tolerated.

Otherwise there would doubt cast over the whole world of floating
point arithmetic.

>

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.

Example: I have values 0.156 and 0.456. The sum is 0.612.

Printing out using 2 decimals, the user will see: 0.16 + 0.46 = 0.61!
By simply rounding to 2 decimals, and then calculating with 0.16 and
0.46, the result 0.62 will now make sense.

This calculation can be done with doubles and will work within wide
limits. You would need a lot of additions for the inaccuracy to have
an effect.


BTW I am on Jacob's side on this. He seems a practically minded chap
(like me). Perhaps instead of bullying, his solution can be refined
until it's acceptable.

His code (one version) I think wouldn't work with negative values (an
fabs() and a sign() is needed somewhere). It also seems to rely on an
integer intermediate value which would overflow sometimes; an fint()
is needed in there. (Sorry don't know the C equivalents: fint(x) would
convert 31.459 to 31.000)

Bart