peternilsson42 wrote: > > > Christopher Coale <chris95...@...> wrote: > > Paul Herring wrote: > > > billcu34<bill...@...> <mailto:billcu1%40suddenlink.net>> wrote: > > > > > double Sma(double *ds, int size) > > > > > { > > > > > double res = 0; > > > > > for (int i = 0; i < size; i++) > > > > > res += ds[i]; > > > > > return ds / (double)size; > > > > > } > > > > > > > > My compiler complained about the ds in the return statement. > > > > It wanted this I guess 'cause I changed it and it accepted. > > Guessing is bad programming. The error is that ds has pointer > type. You can't divide a pointer. > > > > It should in fact read > > > return res/size; > > Which highlights the need to find the source of errors, > rather than just band-aiding them. > > <snip> > > Yeah, my mistake. I didn't bother testing - I just typed it > > in the e-mail quickly. > > > > Casting to a double is to avoid compiler warnings > > A bad practice. You silenced the warning but completely > ignored why it was issued. So instead of fixing the > problem, you white-washed it. > > > (which will just make that a cast anyways). > > Not sure what you're saying here. Without the cast, there > is an implicit conversion of size from int to double. A cast > is an explicit conversion, but a conversion is not a cast. > > > I could have used a double as the parameter, but why? > > It needs a whole number > > Yes, but why? > > > (which generally isn't going to need to be 64-bits, > > let alone 32) > > You seem to have a keen eye for irrelevancies. ;-) > > Why focus on its precise width? And did you mean '32-bits, > let alone 64'? > > > - int is perfect for that. > > But size_t is better. Since it's necessarily big enough to > store the size of the whole array, it must be big enough to > store the number of elements. Neither of those guarantees > hold for int. > > I have used 8MB implementations where int was still only > 16-bit. I dare say there are some embedded environments > where this is still the case. > > You could argue that size_t may have performance issues > because it is often wider than int. But I've yet to encounter > an implementation where the performance actually warranted > a smaller/faster type. > > True, on some systems wider types can be fractionally slower, > but you're not likely to encounter an implementation where > size_t is particularly slow. > > Only on 8-bit micros have I encountered data registers that > are smaller than address registers. On such systems, decent > compilers will often utilise address registers for wide > integer types (even int) precisely because of their speed. > > -- > Peter > > Er... my whole point was that 1) I didn't try compiling, I just typed the code in the e-mail really quick. 2) It really doesn't matter that I casted to a double, why would it? And yes, I didn't mean to reverse my "let alone" phrase. But my point was relevant to the same sentence it was in - that I didn't need a 64-bit double. And what I meant to actually say was that chances are it wouldn't even need a 32-bit int.
The difference between "implicit casting" and conversion is a very, very fine line. So, now, I don't get what you are saying. Are you saying that I shouldn't cast the int to a double? If so, why not? And if not, what exactly are you saying? I am casting the int to a double so that the division is done correctly with an expected result (as well as indirectly get rid of a compiler warning - which just so happens to show up for the same reason I am casting to a double). I'll go crawl back under my rock now...
