   why standard library
  Why would the c standard library still have an overloaded sqrt() function when they made a less ambiguous sqrtf() function? Visual Studio cries mentally deficiency with this "ambiguous" code! int num = 0;sqrt(num);(int)sqrt(num); Is it just for the sake of standards and becuase so many project still use it and have used it in their past projects that they are still persuing?   
Quote:Original post by Mad_CoderWhy would the c standard library still have an overloaded sqrt() functionThat's impossible, because C does not have the concept of overloading.   ;  Do you possibly mean the C++ standard library?  C does not have overloads.C++ overloads std::sqrt() so it can provide different levels of precision.  std::sqrt() has overloads for float, double, std::complex and std::valarray<T>.  It does not provide overloads for integral types because sqrt() is not closed on the set of integers.  The compiler is right to balk at doing automatic conversions because it would be wrong to assume how you want to handle projections from real-valued (or complex-valued or vector-valued) results into integral results and how you want to handle the loss of precision.   ;  Yeah, that's true!   ;  C doesn't support function overloading. I think you mean C++, sqrt from cmath.sqrtf is a step back because you have to know the type of the value. On the other hand, sqrt computes the square root of any value it supports, float, double and long double. It's great especially for templates.template <typename T>class Vector {    T x, y;    T length() const { return std::sqrt(x * x + y * y);};It would be difficult (or at least not straightforward) to implement such functionality with sqrtf, sqrtl etc.As for your case, sqrt doesn't support int, so you have to:a) implement sqrt for intb) convert int to one of float, double, long doubleThe second option is better in 99% of times.   ;  Yes, agreed, std::sqrt should be used instead.I actually think float=sqrt(float) may likely optimize to floating point square root opcode anyway, but I wouldn't bet money on this because without unsafe-math or similar option, optimizations are not allowed to affect results of calculations, and result of sqrt that's given float and converted to float might differ between float sqrt opcode and double sqrt opcode.   ;  What do you mean by "float sqrt opcode" and "double sqrt opcode" ? On x86 architecture there is only one sqrt opcode for FPU - 0xD9 0xFA. It operates with FPU stack registers, not with float/double values in memory.   ;Quote:Original post by bubu LVWhat do you mean by "float sqrt opcode" and "double sqrt opcode" ? On x86 architecture there is only one sqrt opcode for FPU - 0xD9 0xFA. It operates with FPU stack registers, not with float/double values in memory.Well, I have x86-64 , and I've been using SSE for ages. If I recall correctly, it (SSE or SSE2) has two opcodes for single and double precision. Double precision square root takes considerably longer to execute in hardware than single precision.edit: indeed, there is sqrtsd (SSE2+) and sqrtss (SSE1 if i recall correctly). So it does make sense to use the square root of just the required precision.[Edited by - Dmytry on May 16, 2009 4:47:38 PM];Quote:Original post by rozz666As for your case, sqrt doesn't support int, so you have to:a) implement sqrt for intb) convert int to one of float, double, long doubleThe second option is better in 99% of times.Instead of casting or converting the value yourself, you can explicitly specify which template type to use; then the conversion will be implied. It amounts to the same amount of code, but I find it neater somehow.(Integer square-root isn't hard to implement in integer-only operations, BTW. If I'm thinking clearly, it would be comparable performance-wise to an integer division implemented in software. But I can't think when you would need it.)   ;Quote:Original post by ZahlmanInstead of casting or converting the value yourself, you can explicitly specify which template type to use; then the conversion will be implied. It amounts to the same amount of code, but I find it neater somehow.But std::sqrt is not a templated function as far as I remember, or is it?Quote:Original post by Zahlman(Integer square-root isn't hard to implement in integer-only operations, BTW. If I'm thinking clearly, it would be comparable performance-wise to an integer division implemented in software. But I can't think when you would need it.)I was actually thinking about implementing sqrt(int) in terms of sqrt(double) or sqrt(float) (but here we have the problem which type is big enough, or there may be none, so it won't be portable).