Rounding double

[James Kuyper]

Bart said: ....

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:


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: <[email protected]>

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

 

[Bart]

James Kuyper said:

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:

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

 

[Harald van Dijk]

Since the consequences of a #pragma directive that doesn't start with
STDC are implementation-defined, just about anything could, in principle
be achieved use of one. However, for a conforming implementation of C,
Adding

#include <math.h>

at file scope must behave as if it sets up declarations for all of the
math.h functions, definitions for some typedefs, and #defines of the
math.h macros.

A translation unit must contain at least one external declaration; the
declarations which math.h must set up cause this translation unit to
meet that requirement.

So even if an implementation supports and uses nothing more than
#pragma CC magically_define_math_stuff
in its implementation of <math.h>, that must behave as one or multiple
external definitions? That's good to know, thanks.

 

[James Kuyper]

So even if an implementation supports and uses nothing more than
#pragma CC magically_define_math_stuff
in its implementation of <math.h>, that must behave as one or multiple
external definitions? That's good to know, thanks.

That's my interpretation of the grammar as explained in n1256.pdf, which
isn't an official version of the standard.

I find it a bit odd. I can understand why the standard might mandate the
presence of at least one external definition in each translation units;
translation units without any external definitions are fairly useless
[1]. However, what section 6.9 requires is at least one external
declaration; and an external declaration is not sufficient to make a
translation unit useful.

[1]: unless the translation unit contains main(). However, such a
translation unit would contain no external definitions only if one of
the implementation-defined alternative ways of defining main allowed the
use of the 'static' keyword.