Decimal - trig and power support for System.Decimal?

Decimal - trig and power support for System.Decimal?

• khaladu

  Yes I just found such a request pre-existing in the Product Feedback, and have added a comment to it (yeah I voted too).
  
  The use of Decimal for financial and monetary purposes is how the type is being marketed, but that thinking is very limiting as Decimal is extremely powerful.
  
  Eventually all of the System.Math functions should natively support System.Decimal
  
  nobugz - Did you even look at the link I provided IEEE 754r is an extension of the Binary Floating-Point Arithmetic Standard IEEE 754 and says nothing of its use having to be for monetary purposes.
  
  System.Decimal implements a subset of IEEE 754r and as I said 'markets its use for monetary purposes'. Don't let them brainwash you into thinking that is all it's good for!
  
  

• Camillo777

  Anyhoo, I did some more searching on VS2005 Product Feedback. The sequel to VS2005 (Orcas) will not have a higher precision floating point type, not even to bring back the 10 byte 'long double' [currently the keyword 'long double' just maps to regular 8 byte double] (although intermediate double calculations are currently done in the 10 byte type).  They say it is a fairly significant work item (either its importance or in the amount of work it will take) but are lacking the resources (manpower) to get to it.
  
  Slightly disheartening ... well I still have some hope for native Decimal support in Math.Pow, which is a Product Suggestion that has been reviewed by Microsoft and has decidedly been kept open for some time now. That would be the single most important function for me. The trig functions aren't as important, as much of my related work involves vector math and cos/sin can be done with cross/dot product.
  
  So I'll just say my question was answered and turn to some more important matters ...
  
  Thanks for your time nobugz !
  
  

• Node_Pointer

  OK, we're getting to the root of the problem here. I'm an engineer and I never needed more than 4 significant digits. Five in a pinch with good glasses on. They made me buy a calculator to replace the slide-rule. I loved the slide rule, the HP reverse RPN calculator still sticks in my mind as a very expensive purchase for no doggone good ($350 > $10). I was very poor back in those days... But loved the programming part.
  
  Tell us what you're trying to calculate here. Unless your trying to find the difference between floating point numbers that are very close in value, it sounds like you're trying to solve a quantum physics singularity...
  
  
  

• WarrenT

  I'm sorry, I don't think we'll ever agree on this. Adding support for complex numbers would be quite defendable too. If not more, there's (arguably) more use for them. None of this stuff is impossible, .NET is very much designed around the notion of being able to extend the object tree wiith your own favorite classes. C++ pioneered this concept and it is all just straight-forward OOP. If you're looking for somebody to do it for you, and test it, and prove it, and provide a support website if it doesn't work, then I'd turn to the IBM dude...
  
  Meanwhile, I'll Google it if I need it and I don't want to know about it until I need it. Hope it didn't sound offensive, but I look at it from across the rail-road...
  
  
  

• AWolf

  For interests, the feedback submitted by CPP_Standard is https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx FeedbackID=183192.

  
  
  

• NetPochi

  Yes, problem is primarily 'difference between floating point numbers that are very close in value'. Extremely accurate/precise collision/intersection detection.  Similar to the issues associated with getting resting/sliding contact calculations correct in a physics simulation.
  
  Also I have a 64bit random number generator. To convert the random number to a value between [-1,1] or [0,1] it makes more sense to do the mapping using a higher precision floating point type, and then after that I can cut off the extra precision and stick in a double. For such purposes System.Decimal works very well (but I used to use my doubledouble type back when it worked).
  
  Sure,
  yeah eventually I want to simulate some physics where large and small bodies are together. Anytime large and small values are in the same equation there is a chance of problems in the math. I get much better odds with doubledouble.
  
  Adding a small epsilon to a large number just gets you the original number back. That doesn't really help me. With the numbers I work with the math works when I use doubledouble.
  
  After taking a couple numbers and putting them through hundreds of thousands of arithmetic operations with other numbers of varying size, you start to build up some error, and the more precision there is to work with the smaller that error will be.  And at the end you can bump back to double and hopefully all the error was in the part that was truncated off.
  
  

• JRDodd

  nobugz - Right. Sure, I understand. Realize though that I'm not just complaining. As you said, I too only care when I need it. And I do need it, I've been needing it.
  
  double has given me plenty of problems with its lack of precision. This has been happening over and over to me for about 4 years now. I have twice now tried to port a doubledouble implementation to C++ (and once to C#). And I guess I'm just not cut out for it.
  
  My latest C++ attempt actually was professional and worked in Visual Studio 2003 (and took a month). I had to rebuild the libraries for VS2005 and everything is really just broken and I've about given up on it :(
  
  -----
  Yeah, that is why I am just waiting for MS to do it for me, and just give us a doubledouble type or extend Decimal's support to the full set of math functions.
  
  

• Exploder

  Also let me add that I would settle for a System.DoubleDouble (or whatever they would call it - a 16 byte floating point type).
  
  I need more precision than System.Double. And for my purposes that is way more important than the extra accuracy afforded by internally representing the number in decimal.
  
  But for now there is no DoubleDouble. And since expanding support for an existing type seems easier than asking for a whole new type, I will try at least a little to expand the support for Decimal until DoubleDouble arrives.
  
  Yeah and I am stuck with using currently available 3rd party packages for DoubleDouble and implementations of Decimal that have full math function support. But yeah that is lame, from my experience they are way buggy and have plenty of problems. I really hate resorting to this. At least DoubleDouble packages have been out for years, I don't see what MS is waiting for to implement it themselves
  
  

• xRuntime

  Hmm, how often does one take the sine of a dollar or the square root of a penny This is highly specialized functionality and adding it to the BCL would make it so much more harder to absorb. Not even Java with its bloated class library added transcendental functions to its BigDecimal class. Just look around for a dedicated assembly that can give you what you need or make your own.
  
  You can record feature requests at Product Feedback. With enough votes, MSFT is bound to take notice.
  
  
  
• Decimal - trig and power support for System.Decimal?