This project has moved. For the latest updates, please go here.
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 versioning policy, 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 these plans.

General Changes

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

Statistics Changes

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

Matrix Changes

  • 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.)
  • Seal matrix classes.
  • Use verb-form method names. For example, LUDecompose instead of LUDecomposition.

Function Changes

  • Change names of LeftGamma and RightGamma to LeftRegularizedGamma and RightRegularizedGamma.

Last edited Sep 9, 2010 at 8:19 AM by ichbin, version 6


itvieira Nov 8, 2010 at 3:37 PM 
This is one of the most promising numerical library for .NET, good work! I'd like to make two suggestion for inclusion in future versions:

1) Add the SVD decomposition to the matrix classes, this is a must have for a matrix library and not so difficult to implement;

2) Add the Kruskal–Wallis non-parametric testing, this is just an extension to the existing anova.

Many thanks,