There will be one or two more "dot releases" of Meta.Numerics after 1.4, then a "major" release of 2.0. According to our
, a major release is an opportunity for us to improve Meta.Numerics in ways that break backward compatibility. This page describes some of our plans for 2.0. Feel free to leave comments, start a discussion, or write back with comments on
- Compile against .NET 3.5 instead of .NET 2.0. (Do not move all the way to .NET 4.0; it's good to be able to support people who are still "one version behind" the current .NET release.)
- Use the Func delegate from .NET 3.5 in place of our Function delegate. (Do not use the Complex structure from .NET 4.0 in place of our Complex structure, because it does not exist in .NET 3.5.)
- Remove setter from complex structure so that it beomes immutable.
- Rename the DataSet class so that it does not conflict with the DataSet class in the System.Data namespace.
- Use the generic DataPoint<T> type in place of the non-generic DataPoint type everywhere. (Currently DataPoint is simply equivilent to DataPoint<double>, without adding any functionality.)
- Have the Distribution class contain only functionality that is common to ContinuousDistribution and DiscreteDistribution classes, which will both inherit from it. (Move its current functionality specific to continuous distributions into a new ContinuousDistribution
- Move all distributions into a sub-namespace Meta.Numerics.Statistics.Distributions.
- Move UncertainValue and UncertainMath into the System.Numerics core namespace.
- Remove Sample.FitToNormal and Sample.FitToExponential; they are superceeded by Sample.MaximumLikelyhoodFit.
- Change MannWhitneyDistribution to DiscreteDistribution, perhaps even internalize-it.
- Consider renaming all the data collection classes to more clearly differentiate their use. (Make this change only if we can come up with a really good naming scheme.)
- Have GetHashCode() on matrix classes throw InvalidOperationException(). They are not immutable and so should not be used as hash keys. Consider also removing equality testing from matrix classes; testing floating point numbers for strict equality is almost
never the right thing to do and supporting it on matrices allows this generally bad practice to be done N^2 times in very innocuous-looking code.
- Introduce a class hierarchy for matrices. In contrast to an interface hierarchy, a class hierarchy can define operator overloads. This will allow us to avoid having to write an operator overload specific to every possible pair of matrices. (We may still
write some specific overloads to take advantage of structure.)
- Use verb-form method names. For example, LUDecompose instead of LUDecomposition.
- Change names of LeftGamma and RightGamma to LeftRegularizedGamma and RightRegularizedGamma.