[
https://issues.apache.org/jira/browse/MATH-608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13058536#comment-13058536
]
Luc Maisonobe commented on MATH-608:
------------------------------------
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: MATH-608
> URL: https://issues.apache.org/jira/browse/MATH-608
> 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 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
