commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gilles (Updated) (JIRA)" <>
Subject [jira] [Updated] (MATH-608) Remove methods from RealMatrix Interface
Date Tue, 07 Feb 2012 12:27:00 GMT


Gilles updated MATH-608:

    Fix Version/s:     (was: 3.0)

> Remove methods from RealMatrix Interface
> ----------------------------------------
>                 Key: MATH-608
>                 URL:
>             Project: Commons Math
>          Issue Type: Improvement
>    Affects Versions: 1.0, 1.1, 1.2, 2.0, 2.1, 2.2
>         Environment: Java
>            Reporter: greg sterijevski
>            Priority: Minor
>              Labels: Matrices
>             Fix For: 4.0
>   Original Estimate: 2h
>  Remaining Estimate: 2h
> The RealMatrix interface describes several methods which take a RealMatrix and yield
a RealMatrix return. They are:
>     RealMatrix multiply(RealMatrix m);
>     RealMatrix preMultiply(RealMatrix m);
>     RealMatrix power(final int p);
>     RealMatrix add(RealMatrix m)
>     RealMatrix subtract(RealMatrix m)
> There is nothing inherently wrong in making all subclasses of RealMatrix implement these
methods. However, as the number of subclasses of RealMatrix increases, the complexity of these
methods will also increase. I think these methods should be part of a separate class of 'operators'
which handle matrix multiplication, addition, subtraction and exponentiation.
> Say for example, I implement SymmetricRealMatrix. I would like to store the data of a
real symmetric in compressed form, so that I only consume (nrow + 1)*nrow /2 space in memory.
When it comes time to implement multiply (for example), I must test to see if the RealMatrix
given in the argument is also of Type SymmetricRealMatrix, since that will affect the algorithm
I use to do the multiplication. I could access each element of the argument matrix via its
getter, but efficiency will suffer. One can think of cases where we might have a DiagonalRealMatrix
times a DiagonRealMatrix. One would not want to store the resultant diagonal in a general
matrix storage. Keeping track of all of the permutations of Symmetrics, Diagonals,..., and
their resultants inside of the body of a function makes for very brittle code. Furthermore,
anytime a new type of matrix is defined all matrix multiplication routines would have to be
> There are special types of operations which result in particular matrix patterns. A matrix
times its transpose is itself a symmetric. A general matrix sandwiched between another general
matrix and its transpose is a symmetric. Cholesky decompositions form upper and lower triangular
matrices. These are common enough occurrences in statistical techniques that it makes sense
to put them in their own class (perhaps as static methods). It would keep the contract of
the RealMatrix classes very simple. The ReaMatrix would be nothing more than:
> 1. Marker (is the matrix General, Symmetric, Banded, Diagonal, UpperTriangular..)
> 2. Opaque data store (except for the operator classes, no one would need to know how
the data is actually stored).
> 3. Indexing scheme. 
> The reason I bring this up, is that I am attempting to write a SymmetricRealMatrix class
to support variance-covariance matrices. I noticed that there are relatively few subclasses
of RealMatrix. While it would be easy to hack it up for the handful of implementations that
exist, that would probably create more problems as the number of types of matrices increases.
> Thank you,
> -Greg 

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


View raw message