Now that I'm back I'll try to catch up on this thread quickly
Phil Steitz wrote:
Kim van der Linde wrote:
Hi Phil,
I have been thinking for a few days on the Matrix classes.
I think the Matrix class itself should contain all those methods that do matrix calculations (add, subtract, multiply) that either a Matrix themselfs or proporties of the Matrix (isSingular for example).
I agree.
I have a slightly differing opinion of this, I do think we should have specific methods for these tasks, but that they delegate to "Helpers" that act to organize the code and allow for various forms of subclassing and OO design principles.
for instance
public interface MatrixFunction{
public RealMatrix execute(double[][] a, double[][] b);
}
public RealMatrix add(RealMatrix m){
MatrixFunction addFunct = new MatrixFunction(){ public RealMatrix execute(double[][] a, double[][] b){validateMatricies(a,b);
int rowCount = a.length;
int columnCount = a[0].length;double[][] outData = new double[rowCount][columnCount];
for (int row = 0; row < rowCount; row++) {
for (int col = 0; col < columnCount; col++) {
outData[row][col] = data[row][col] + m.data[row][col];
}
}
return new RealMatrixImpl(outData);
}
};return addFunct.execute(data, m.data); }
what this allows us to do is provide customization of such processing in the following sort of example;
public Matrix apply(MatrixFunction funct){
return funct.execute(double[][] a, double[][] b);
}This allows us to expose certain capabilities to the advanced user while keeping the encapsulation under control for the common user. The Common user is less likely to make mistakes in handling the object, we can separate the ideas of building customizations and properly handling internal objects from that of the user who just wants to add two matrices.
The mean
methods (getRowMeans) etc are statistics done ON a matrix, and I think they should be in a seperate class, maybe called MatrixStats. This enables aso he option to add variances and SD's which are needed for column mean resp mean-SD standardizations, to be used for example in PCA calculations when a covariance resp. correlation matrix is used.
I agree here as well. Do you see use cases where you will want to start with a double[][] array, perform matrix operations on it (say some decomposition) and then run stats on the resulting matrix? Will it be too onerous to make copies of the double[][] at each stage? If so, we need to think about access to the double[][].
I don't think a single static utility class will be able to maintain all this content in a fashion that allows for reuse, its the same argument I maintained for the Statistics API during its refactoring. You can have a MatrixStats class that provides nice static access to these capabilities, but I think that actual implementations should be in separate classes so they can easily be reused, customized, extended etc.
Is there the intention to add an EigenvalueDecomposition class to the package? In that case, which algorithm is targeted to be used? Jacobi?
We have not discussed this. Feel free to add to the wish list and propose an algorithm. We also need to discuss how best to implement the strategy pattern for decompositions in general, as there will often be multiple algorithms to choose from.
An example of the need for this sort of design pattern, especially in Linear Algebra, there are many many customized strategies for doing various tasks on matrices for Eigenvalue decomposition via numerical methods, a well organized framework will give us a landscape upon which to implement theses strategies. Otherwise, again you end up with large Static Classes with no room for extensibility.
-Mark
-- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
