This project has moved and is read-only. For the latest updates, please go here.

On decimal and double

Topics: Core Library Development, Suggest a feature
Aug 6, 2013 at 7:20 AM
As I see the core is always using decimal for non integer values. As you know this is not a good choice when you are doing computations and it also forces a lot of castings and conversions. Why you have not used double in some parts?
Aug 6, 2013 at 9:01 AM
The choice of decimal was mainly because it would store the number in a more or less exact form (although it can be argued that it is exact) and because it would be of an advantage to use the same type across the entire library. Some parts require decimal like Finance.cs. However, I see what you mean. As I know right now, DifferentialCalculus.cs needs to be changed to double (which I am going to change soon). Could you please give me a list of those modules that you would recommend to use double instead of decimal. Below, a list of modules I think would need double.
  • DifferentialCalculus.cs
  • FractionType.cs
  • FractionType.cs
  • ComplexNumberType.cs
Aug 6, 2013 at 10:04 AM
In my opinion it is good to do most of the modules in both ways. I also guess that ComplexNumberType is redundant unless we want to have Complex numbers containing decimal parts, due to existence of System.Numerics.Complex which has double parts. I think
we better adopt known good open source algorithms for Numerical Methods. I will check classes which I guess need to be "doubled" and tell you in forward
Aug 6, 2013 at 9:39 PM
OOps I wrote a lot of things for you here but they were lost! My first question: does your implementation of Complex Numbers do something better than System.Numerics.Complex? If yes let me extend and enhance it.