commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark R. Diggory" <mdigg...@latte.harvard.edu>
Subject Re: [math] Matrix subMatrix and mean methods
Date Tue, 05 Oct 2004 16:12:06 GMT
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message