[LCP]Rounding questions

[Chuck Martin]

On Fri, Sep 06, 2002 at 01:29:54AM +1000, Greg Black wrote:
> Chuck Martin wrote:
> | The %f takes a double.  If I change "round((double) 390.0)" to
> | "(double) 390.0", the output is "390.000000" and a newline.
> 
> If you left out all these pointless casts, it would be easier to
> believe that you knew what you were doing.

I agree they are pointless, and my original tests did not include
them.  I started out with "round(390)", and only added the casts
to make sure everything was being interpreted as doubles.

>                                             What you've shown us
> looks like a bug in your implementation of round(), but there is
> so much superfluous noise and so little clear exposition of
> exactly what you did and what happened that it's difficult to be
> sure about this.

How can you say there was "so little clear exposition of exactly
what you did and what happened" when I not only listed the test
program source file verbatim, but also the command line used to
compile it and the complete (all one line of it, plus the newline)
output of the program?

> A complete minimal program and the compilation line used to
> build it and the complete output would be a good start.  The
> whole thing should be about five lines of C, one compilation
> line and one line of output.

And you didn't see that in my previous messages?

> Just for the benefit of the C newbies, "(double) 390.0" is in
> fact identical to "390.0" -- the cast adds absolutely nothing
> and only obfuscates the code.

On the contrary, rather than obfuscate the code, it "needlessly"
clarifies it.  Superfluous castings are merely ignored by the
compiler, but make it clear exactly what arguments are being
passed and what is expected to be returned.

>                                Equally, in other examples, where
> a prototype is in scope there is no point in casting arguments
> to functions where those arguments are declared in the function
> prototype.

Agreed.  As I stated above, my first test program merely used
"round(390)", which means that the argument is an integer, but
should be promoted to a double by the compiler.  When the results
weren't as expected, I added the redundant castings to make sure
this was happening properly.  In the original program where I had
the problem, I didn't use the castings because the argument was
already known to be a double (the argument was the product of the
return value of a function known to return a double and a variable
that was already declared to be a double).

Chuck