457,696 Members | 1,522 Online Need help? Post your question and get tips & solutions from a community of 457,696 IT Pros & Developers. It's quick & easy.

# Why does Math.Sqrt not take a decimal?

 P: n/a Hi, Why does Math.Sqrt() only accept a double as a parameter? I would think it would be just as happy with a decimal (or int, or float, or ....). I can easily convert back and forth, but I am interested in what is going on behind the scenes and if there is some aspect of decimals that keep them from being used in this calculation. Thanks! Ethan Ethan Strauss Ph.D. Bioinformatics Scientist Promega Corporation 2800 Woods Hollow Rd. Madison, WI 53711 608-274-4330 800-356-9526 et***********@promega.com Jun 27 '08 #1
13 Replies

 P: n/a Ethan Strauss Web site: http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet C# in Depth: http://csharpindepth.com Jun 27 '08 #2

 P: n/a Ethan Strauss wrote: Why does Math.Sqrt() only accept a double as a parameter? I would think it would be just as happy with a decimal (or int, or float, or ....). I can easily convert back and forth, but I am interested in what is going on behind the scenes and if there is some aspect of decimals that keep them from being used in this calculation. Usually that type of functions returns a value of the same type as itself. Sqrt of a decimal will not return a true decimal (decimal is supposed to be exact). Sqrt of an int will definitely not return an int. double Sqrt(decimal) and double Sqrt(int) will not follow practice for functions decimal Sqrt(decimal) and int Sqrt(int) will give an impression about the result that is not correct Besides: when do you need to take the square root of 87 dollars ?? :-) Arne Jun 27 '08 #3

 P: n/a All of the variables used by the Math class are primitive types. The CLR does not consider a Decimal to be a primitive type (the CLR does not contain special IL instructions to handle decimal types). I would imagine that is one of the reasonâ¦. maybe??? You can check out the definition of a Decimal and you will see that it implements/overrides just about all the math operators on it including but not limited to +,-,*,/,Round, Ceiling, Floor etc, many of this are also included on the Math class but the Decimal type provides its own implementation. "Ethan Strauss"

 P: n/a Ethan, Why did you think they ever created a double (or value representations like that with other names). (As in the beginning all data was stored only binary in bytes and a while later as so called binary decimals). In my idea it was to do things like Math.Sqrt() Cor "Ethan Strauss"

 P: n/a On Jun 5, 1:44 am, Arne Vajhøj

 P: n/a On Jun 5, 4:08 am, "Rene"

 P: n/a Round, Floor, Ceiling, Max, Min, Truncate, Sign and Abs all have overloads which take decimals. Yes, but if you look at the implementation of these overloads, they are nothing more that a wrapper to the Decimal class. For example: Math.Round will internally call Decimal.Round >Well, doing a square root properly (as opposed to converting todouble, taking the square root and then converting back, which wouldbe a horrible way to go) would certainly be rather slower than whenusing double due to the lack of hardware support. More importantlythough, it just wouldn't be useful for the intended uses of decimal. Exactly, my point was that since there are no special IL instructions for Decimals, getting the square root of a decimal using decimal context wouldnt be very efficient. Jun 27 '08 #8

 P: n/a Rene Web site: http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet C# in Depth: http://csharpindepth.com Jun 27 '08 #9

 P: n/a Jon Skeet [C# MVP] wrote: On Jun 5, 1:44 am, Arne Vajhøj Ethan Strauss wrote: >> Why does Math.Sqrt() only accept a double as a parameter? I would thinkit would be just as happy with a decimal (or int, or float, or ....). I caneasily convert back and forth, but I am interested in what is going on behindthe scenes and if there is some aspect of decimals that keep them from beingused in this calculation. Usually that type of functions returns a value of the sametype as itself.Sqrt of a decimal will not return a true decimal (decimal issupposed to be exact). Decimal operations are exact/accurate in certain well-defined circumstances. There are plenty of operations on decimal which won't give exact results: 1m / 3 for example. True, but division would be missed if it was not there. I would not have a problem if decimal division gave an exception if the result was not exact, but that would probably be too inefficient to test for that. Likewise even addition - both 1e25 and 1e-25 are exactly representable as decimals, but their sum isn't. Which is not good either. But I see your point. Decimal is not exact in other contexts either. I love the concept of decimal, but I hate the implementation chosen. >Sqrt of an int will definitely not return an int. Indeed, but then you wouldn't really want to. >double Sqrt(decimal) and double Sqrt(int) will not followpractice for functions decimal Sqrt(decimal) and double Sqrt(int) would be fine in my view, but the first is useless for typical encouraged uses of decimal, and the second is already available through an implicit conversion from int to double. >decimal Sqrt(decimal) and int Sqrt(int) will give animpression about the result that is not correct Does decimal division give you that impression as well? It can. How about integer division? No, integer division works just as expected. I prefer the Pascal style with one operator for floating point division and another for integer division to emphasize that it is two different operators. Arne Jun 27 '08 #10

 P: n/a On Jun 6, 3:33 am, Arne Vajhøj

 P: n/a Jon Skeet [C# MVP] wrote: On Jun 6, 3:33 am, Arne Vajhøj I would not have a problem if decimal division gave an exceptionif the result was not exact, but that would probably be tooinefficient to test for that. I'd have a massive problem with that, to be honest. I suspect that there are many, many times when you don't mind decimal losing some information, because you're going to round anyway. However, other operations *do* need to be precise, and the input will typically ensure that's the case anyway. I guess I prefer either pure approximative or pure precise. >But I see your point.Decimal is not exact in other contexts either.I love the concept of decimal, but I hate the implementation chosen. I'd like to see BigDecimal in the framework at some point, but decimal has its advantages too (bounded space being the most obvious one). There is usually always a pro and a con. >>>decimal Sqrt(decimal) and int Sqrt(int) will give animpression about the result that is not correctDoes decimal division give you that impression as well? It can. Why? Surely it's a matter of common sense that decimal can't accurately represent all rational numbers exactly. True, but it can give the results that does not follow accounting practices. > How about integer division? No, integer division works just as expected. So what's the difference? It's information loss either way, and should be expected. Division is an inherently lossy operation in computing unless you actually keep both operands. I don't see why losing information in decimal is a problem, but losing information with integers isn't. Integer division is not loosing information. One just need to remember that integer division is not a "normal" division. Decimal division tries do a normal division. >I prefer the Pascal stylewith one operator for floating point division and another for integerdivision to emphasize that it is two different operators. Occasionally that would be useful, but mostly I prefer the consistency. I look at it differently - I find it inconsistent to use the same operator for two fundamentally different operations. Arne Jun 27 '08 #12

 P: n/a Arne Vajhøj Web site: http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet C# in Depth: http://csharpindepth.com Jun 27 '08 #13

 P: n/a Jon Skeet [C# MVP] wrote: Arne Vajhøj Depends on checked switch.:-) Nice, had forgotten that. I forget about that all the time. But System.OverflowException keeps reminding me ! Arne Jun 27 '08 #14

### This discussion thread is closed

Replies have been disabled for this discussion. 