[
https://issues.apache.org/jira/browse/MATH-608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Steitz updated MATH-608:
-----------------------------
Affects Version/s: (was: 3.0)
1.0
1.1
1.2
2.0
2.1
2.2
Fix Version/s: 3.0
Fortunately or unfortunately, we need to resolve this for 3.0.
> Remove methods from RealMatrix Interface
> ----------------------------------------
>
> Key: MATH-608
> URL: https://issues.apache.org/jira/browse/MATH-608
> 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: 3.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 updated.
> 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
