[LCP]Rounding questions

[Greg Black]

Chuck Martin wrote:

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

But what you really show with the casts is that you don't know
what's happening and are trying to work around it.  This is just
never a good idea.  Even if you make such a change to test an
idea, you should immediately establish what is missing and go
and find the real problem.

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

If there was such a message, I missed it.  Sorry.

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

No, superfluous casts merely show that the programmer is unsure
of what s/he is doing.  Casts are almost never required and are
always a flag that says "I don't what's happening here".

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

But this was the wrong thing to do.  The next step should have
been to go looking for the prototype to ensure that it was as
you expected and was in fact being seen.

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

So long as one of the operands of the multiplication is a
double, the other will be promoted and the result will be
double.

Greg