Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Date: Thu, 3 Dec 2015 22:44:10 +0000 (UTC)
From: "Thomas Neidhart (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Message-ID: <JIRA.12512339.1309448770000.266052.1449182650991@Atlassian.JIRA>
In-Reply-To: <JIRA.12512339.1309448770000@Atlassian.JIRA>
References: <JIRA.12512339.1309448770000@Atlassian.JIRA>
 <JIRA.12512339.1309448770549@arcas>
Subject: [jira] [Resolved] (MATH-608) Remove methods from RealMatrix
 Interface
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/MATH-608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Thomas Neidhart resolved MATH-608.
----------------------------------
       Resolution: Duplicate
    Fix Version/s:     (was: 4.0)

Should be discussed as part of MATH-765.

> 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
>   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 was sent by Atlassian JIRA
(v6.3.4#6332)