[ https://issues.apache.org/jira/browse/MATH-608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13082332#comment-13082332 ]
greg sterijevski commented on MATH-608: --------------------------------------- This was not a popular suggestion and would be a major slash and burn operation. Postpone it, or kill it. -Greg > 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