[ https://issues.apache.org/jira/browse/MATH608?page=com.atlassian.jira.plugin.system.issuetabpanels:commenttabpanel&focusedCommentId=13058536#comment13058536
]
Luc Maisonobe commented on MATH608:

I don't understand how you intend to separate the API.
Would that mean users would always have to know beforehand the shape of the matrix they use
and manage both the matrix, the data store and the operators in sync ?
As this feature request will probably involve a long discussion, I think it would be better
to discuss about it on the dev list rather than here, could you move the discussion there
?
> Remove methods from RealMatrix Interface
> 
>
> Key: MATH608
> URL: https://issues.apache.org/jira/browse/MATH608
> Project: Commons Math
> Issue Type: Improvement
> Affects Versions: 3.0
> Environment: Java
> Reporter: greg sterijevski
> Priority: Minor
> Labels: Matrices
> 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 variancecovariance 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
