Rounding double

[Richard Heathfield]

Re: Rounding double

CBFalconer said:

Richard Heathfield wrote:

>jacob navia said:
>>

... snip ...

>>

>>And it IS possible to round correctly a double precision number.

>>
>Show me 0.33 rounded to one decimal place.

>
Hunh? How about:
>
double r = 0.33, s;
>
s = (int)((r * 10.0) + 0.5) / 10.0;
>
which, according to me, gives the desired value in s within the
accuracy limits of doubles.

On my system, it gives 0.2999999999999 99988898, which doesn't even get the
first digit right.

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

Mark McIntyre said:

jacob navia wrote:

>>Could someone else please share with us the result they get when they
>>drive this function with inputs of 0.33 and 1 ? I'm getting some very,
>>very strange results here.

>

>d:\lcc\mc68\te st>type tdouble3.c

>
I copy-pasted this exact code, and compiled under gcc 4.1.2:
>
thelinux clc_tests $ ./a.out 0.33
1374389535.0000 000000000000000 : 0 decimals 1374389535.0000 000000000000
1374389535.0000 000000000000000 : 1 decimals 1374389535.0000 000000000000
>
I'm giving this one a 'strange' score of 'high'

Thanks, Mark, for doing that. I used the exact same code, except that I
read ahead in the thread and added <stdlib.has a result (I didn't get a
warning about atof because I had to switch off many diagnostics to get the
code to compile at all), and I also had to put braces around the last two
lines of roundto. I'm getting the following results:

me@here./foo 0.33
0.3300000000000 000155: 0 decimals 256.00000000000 00000
0.3300000000000 000155: 1 decimals -21474836.000000 0000000000
0.3300000000000 000155: 2 decimals -20468203.000000 0000000000
0.3300000000000 000155: 3 decimals -1522532.0000000 000000000
0.3300000000000 000155: 4 decimals -83414.000000000 0000000
0.3300000000000 000155: 5 decimals -21322.000000000 0000000
0.3300000000000 000155: 6 decimals -1591.0000000000 000000
0.3300000000000 000155: 7 decimals -91.000000000000 0000
0.3300000000000 000155: 8 decimals 0.0000000000000 000
0.3300000000000 000155: 9 decimals -1.0000000000000 000
0.3300000000000 000155: 10 decimals 0.0000000000000 000
0.3300000000000 000155: 11 decimals 0.0000000000000 000
0.3300000000000 000155: 12 decimals 0.0000000000000 000
0.3300000000000 000155: 13 decimals 0.0000000000000 000
0.3300000000000 000155: 14 decimals 0.0000000000000 000

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

Mark McIntyre said:
>

>jacob navia wrote:

>>>Could someone else please share with us the result they get when they
>>>drive this function with inputs of 0.33 and 1 ? I'm getting some very,
>>>very strange results here.
>>d:\lcc\mc68\t est>type tdouble3.c

>I copy-pasted this exact code, and compiled under gcc 4.1.2:
>>
>thelinux clc_tests $ ./a.out 0.33
>1374389535.000 000000000000000 0: 0 decimals 1374389535.0000 000000000000
>1374389535.000 000000000000000 0: 1 decimals 1374389535.0000 000000000000
>>
>I'm giving this one a 'strange' score of 'high'

>
Thanks, Mark, for doing that. I used the exact same code, except that I
read ahead in the thread and added <stdlib.has a result (I didn't get a
warning about atof because I had to switch off many diagnostics to get the
code to compile at all), and I also had to put braces around the last two
lines of roundto. I'm getting the following results:
>
me@here./foo 0.33
0.3300000000000 000155: 0 decimals 256.00000000000 00000
0.3300000000000 000155: 1 decimals -21474836.000000 0000000000
0.3300000000000 000155: 2 decimals -20468203.000000 0000000000
0.3300000000000 000155: 3 decimals -1522532.0000000 000000000
0.3300000000000 000155: 4 decimals -83414.000000000 0000000
0.3300000000000 000155: 5 decimals -21322.000000000 0000000
0.3300000000000 000155: 6 decimals -1591.0000000000 000000
0.3300000000000 000155: 7 decimals -91.000000000000 0000
0.3300000000000 000155: 8 decimals 0.0000000000000 000
0.3300000000000 000155: 9 decimals -1.0000000000000 000
0.3300000000000 000155: 10 decimals 0.0000000000000 000
0.3300000000000 000155: 11 decimals 0.0000000000000 000
0.3300000000000 000155: 12 decimals 0.0000000000000 000
0.3300000000000 000155: 13 decimals 0.0000000000000 000
0.3300000000000 000155: 14 decimals 0.0000000000000 000

Have you any idea why this is happening? I got none of the warnings you
complained about (using -std=c99 -pedantic -W -Wall) and the results
seem to be what Jacob gets. (Of course, if he has invoked UB this means
nothing.)

I do find it ironic that Jacob insists the problem is soluble, but even
after using his rounding he /still/ uses your proposed solution of using
printf() to round on output...

pgp@medusa-s2:~/tmp$ gcc -std=c99 -pedantic -W -Wall -lm jn.c -ojn
jn.c:16: warning: unused parameter 'argc'
pgp@medusa-s2:~/tmp$ ./jn 0.33
0.3300000000000 000155: 0 decimals 0.0000000000000 000
0.3300000000000 000155: 1 decimals 0.3000000000000 000
0.3300000000000 000155: 2 decimals 0.3300000000000 000
0.3300000000000 000155: 3 decimals 0.3300000000000 000
0.3300000000000 000155: 4 decimals 0.3300000000000 000
0.3300000000000 000155: 5 decimals 0.3300000000000 000
0.3300000000000 000155: 6 decimals 0.3300000000000 000
0.3300000000000 000155: 7 decimals 0.3300000000000 000
0.3300000000000 000155: 8 decimals 0.3300000000000 000
0.3300000000000 000155: 9 decimals 0.3300000000000 000
0.3300000000000 000155: 10 decimals 0.3300000000000 000
0.3300000000000 000155: 11 decimals 0.3300000000000 000
0.3300000000000 000155: 12 decimals 0.3300000000000 000
0.3300000000000 000155: 13 decimals 0.3300000000000 000
0.3300000000000 000155: 14 decimals 0.3300000000000 000

I'm disappointed with the misleading results here which suggest that the
LHS has trailing cruft which the RHS doesn't, when both have such cruft.

[Richard Heathfield]

Re: Rounding double

Philip Potter said:

Richard Heathfield wrote:

<snip>

>I used the exact same code, except that I
>read ahead in the thread and added <stdlib.has a result (I didn't get
>a warning about atof because I had to switch off many diagnostics to get
>the code to compile at all), and I also had to put braces around the
>last two lines of roundto. I'm getting the following results:
>>
>me@here./foo 0.33
>0.330000000000 0000155: 0 decimals 256.00000000000 00000
>0.330000000000 0000155: 1 decimals -21474836.000000 0000000000
>0.330000000000 0000155: 2 decimals -20468203.000000 0000000000

[...]

>
Have you any idea why this is happening?

Well, obviously I don't have a C99 compiler (I use gcc, which doesn't
conform to C99 yet), so to avoid changing the code too much I am forced to
rely on gcc extensions (which is why I had to turn off my usual collection
of diagnostic switches). It is possible that one or more of the extensions
don't operate according to C99 rules.

<snip>

I do find it ironic that Jacob insists the problem is soluble, but even
after using his rounding he /still/ uses your proposed solution of using
printf() to round on output...

This rapid accretion of irony over many such threads over several years has
now formed a solid irony cory so large that its gravityy is now having a
significant effect; not only has it attracted a lot of crusty, but it even
appears to have acquired an atmosphery.

<snip>

I'm disappointed with the misleading results here which suggest that the
LHS has trailing cruft which the RHS doesn't, when both have such cruft.

It's all down to smoke and mirrors.

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

Philip Potter wrote:

Richard Heathfield wrote:

[snip]

I'm getting the following results:

>>
>me@here./foo 0.33
>0.330000000000 0000155: 0 decimals 256.00000000000 00000
>0.330000000000 0000155: 1 decimals -21474836.000000 0000000000
>0.330000000000 0000155: 2 decimals -20468203.000000 0000000000
>0.330000000000 0000155: 3 decimals -1522532.0000000 000000000
>0.330000000000 0000155: 4 decimals -83414.000000000 0000000
>0.330000000000 0000155: 5 decimals -21322.000000000 0000000
>0.330000000000 0000155: 6 decimals -1591.0000000000 000000
>0.330000000000 0000155: 7 decimals -91.000000000000 0000
>0.330000000000 0000155: 8 decimals 0.0000000000000 000
>0.330000000000 0000155: 9 decimals -1.0000000000000 000
>0.330000000000 0000155: 10 decimals 0.0000000000000 000
>0.330000000000 0000155: 11 decimals 0.0000000000000 000
>0.330000000000 0000155: 12 decimals 0.0000000000000 000
>0.330000000000 0000155: 13 decimals 0.0000000000000 000
>0.330000000000 0000155: 14 decimals 0.0000000000000 000

>
Have you any idea why this is happening? I got none of the warnings you
complained about (using -std=c99 -pedantic -W -Wall) and the results
seem to be what Jacob gets. (Of course, if he has invoked UB this means
nothing.)
>
I do find it ironic that Jacob insists the problem is soluble, but even
after using his rounding he /still/ uses your proposed solution of using
printf() to round on output...
>
pgp@medusa-s2:~/tmp$ gcc -std=c99 -pedantic -W -Wall -lm jn.c -ojn
jn.c:16: warning: unused parameter 'argc'
pgp@medusa-s2:~/tmp$ ./jn 0.33
0.3300000000000 000155: 0 decimals 0.0000000000000 000
0.3300000000000 000155: 1 decimals 0.3000000000000 000
0.3300000000000 000155: 2 decimals 0.3300000000000 000
0.3300000000000 000155: 3 decimals 0.3300000000000 000
0.3300000000000 000155: 4 decimals 0.3300000000000 000
0.3300000000000 000155: 5 decimals 0.3300000000000 000
0.3300000000000 000155: 6 decimals 0.3300000000000 000
0.3300000000000 000155: 7 decimals 0.3300000000000 000
0.3300000000000 000155: 8 decimals 0.3300000000000 000
0.3300000000000 000155: 9 decimals 0.3300000000000 000
0.3300000000000 000155: 10 decimals 0.3300000000000 000
0.3300000000000 000155: 11 decimals 0.3300000000000 000
0.3300000000000 000155: 12 decimals 0.3300000000000 000
0.3300000000000 000155: 13 decimals 0.3300000000000 000
0.3300000000000 000155: 14 decimals 0.3300000000000 000
>
I'm disappointed with the misleading results here which suggest that the
LHS has trailing cruft which the RHS doesn't, when both have such cruft.

1: This is because I forgot in the format specifier of the LHS to
imit to DBL_DIG.
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.
3: It is interesting to note that you say that my solution doesn't
work when you see correct results in your machine.

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

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

[Richard Heathfield]

Re: Rounding double

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.

And no, I didn't make those results up.

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

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.
>
And no, I didn't make those results up.
>

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.

And if I have a minor error somewhere correct it instead
of just spreading FUD

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

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

[Richard]

Re: Rounding double

jacob navia <jacob@nospam.c omwrites:

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.
>>
>And no, I didn't make those results up.
>>

>
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.
>
And if I have a minor error somewhere correct it instead
of just spreading FUD

So that would be the "minor error in the code to trip about" option from
RH then. Good to see nothing much changes with regard to his superiority
complex.

[Richard Heathfield]

Re: Rounding double

jacob navia said:

<snip>

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:

gcc -o foo foo.c -lm

If the system matters, then presumably you agree that your code is not
portable C, and specify on which systems or classes of system you expect
your code to work. But I'll tell you anyway: AMD Athlon XP1600+ running at
1.4GHz.

And if I have a minor error somewhere correct it instead
of just spreading FUD

The correction is easy:

rm foo.c

del foo.c

....or whatever local command does the equivalent (i.e. delete the source
file).

I recommend this correction to the OP, since the program you posted
completely fails to solve the original problem that he posed. It can't be
corrected for the simple reason that the problem as stated cannot be
solved, as I have already pointed out several times in this thread.

And no, I'm not spreading FUD. Fear doesn't enter into it, and there is no
doubt, no uncertainty, whatsoever that your code does *not* solve the
problem stated by the OP. It attempts to solve a different problem, and
does so in a non-portable manner (because otherwise I'd get the same
results that you do).

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

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.

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


Best

Kai-Uwe Bux

[jacob navia]

Re: Rounding double

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

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.

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

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.

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 ".
>
>
Best
>
Kai-Uwe Bux

This is exactly my position.

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

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

[Richard Heathfield]

Re: Rounding double

jacob navia said:

<snip>

All trascendental functions, sqrt, pow, whatever. All of them yield
approximations 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).

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

>
<snip>
>

>>I used the exact same code, except that I
>>read ahead in the thread and added <stdlib.has a result (I didn't get
>>a warning about atof because I had to switch off many diagnostics to get
>>the code to compile at all), and I also had to put braces around the
>>last two lines of roundto. I'm getting the following results:
>>>
>>me@here./foo 0.33
>>0.33000000000 00000155: 0 decimals 256.00000000000 00000
>>0.33000000000 00000155: 1 decimals -21474836.000000 0000000000
>>0.33000000000 00000155: 2 decimals -20468203.000000 0000000000

[...]

>Have you any idea why this is happening?

>
Well, obviously I don't have a C99 compiler (I use gcc, which doesn't
conform to C99 yet), so to avoid changing the code too much I am forced to
rely on gcc extensions (which is why I had to turn off my usual collection
of diagnostic switches). It is possible that one or more of the extensions
don't operate according to C99 rules.

You may have noticed I used gcc too. I have no qualms about using
-std=c99 when I know it not to be fully-conformant; it appears you do.

>I do find it ironic that Jacob insists the problem is soluble, but even
>after using his rounding he /still/ uses your proposed solution of using
>printf() to round on output...

>
This rapid accretion of irony over many such threads over several years has
now formed a solid irony cory so large that its gravityy is now having a
significant effect; not only has it attracted a lot of crusty, but it even
appears to have acquired an atmosphery.

"significan ty effecty" surely? :)

[Philip Potter]

Re: Rounding double

jacob navia wrote:

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.

Given that you use long long and RH doesn't have a C99 compiler and
doesn't use -std=c99 on gcc, I don't think results on his (or even my)
machine are too meaningful.

3: It is interesting to note that you say that my solution doesn't
work when you see correct results in your machine.

Er, if you're referring to this:

>I do find it ironic that Jacob insists the problem is soluble, but
>even after using his rounding he /still/ uses your proposed solution
>of using printf() to round on output...

...then I think it stands for itself. The reason your solution works is
because you use printf() to cut off the rounding error; RH's solution
used *exactly the same feature of printf()* to round.

[Philip Potter]

Re: Rounding double

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.