Jump to content
  • Advertisement
Sign in to follow this  
Mad_Coder

why standard library

This topic is 3494 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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?

Share this post


Link to post
Share on other sites
Advertisement
Quote:
Original post by Mad_Coder
Why would the c standard library still have an overloaded sqrt() function

That's impossible, because C does not have the concept of overloading.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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 int
b) convert int to one of float, double, long double

The second option is better in 99% of times.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Quote:
Original post by bubu LV
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.

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]

Share this post


Link to post
Share on other sites
Quote:
Original post by rozz666
As for your case, sqrt doesn't support int, so you have to:
a) implement sqrt for int
b) convert int to one of float, double, long double

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

Share this post


Link to post
Share on other sites
Quote:
Original post by Zahlman

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.


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

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!