Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Received-SPF: pass (hermes.apache.org: local policy)
Message-ID: <416AD8C1.9000109@latte.harvard.edu>
Date: Mon, 11 Oct 2004 15:02:25 -0400
From: "Mark R. Diggory" <mdiggory@latte.harvard.edu>
Reply-To: mark_diggory@harvard.edu
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
MIME-Version: 1.0
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
Subject: Re: [math] RealMatrixImpl  changes was: RE: cvs commit:
 jakarta-commons/math/src/test/org/apache/commons/math/linear
 RealMatrixImplTest.java
References: <95F1CCA52E317C49AB7AA71B16E8988B0C2396@mail2.tsd.biz>
In-Reply-To: <95F1CCA52E317C49AB7AA71B16E8988B0C2396@mail2.tsd.biz>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit


Phil Steitz wrote:
> Mark,
>  
> I now see (more fully) what you mean about the extra copy operations and agree that there is a little more to do than what I responded below.  Using getElement and getDataRef for the current instance should suffice, however, in most cases.  I need to understand better what you are proposing.
>  
> Phil
> 
> 	-----Original Message----- 
> 	From: Phil Steitz 
> 	Sent: Mon 10/11/2004 10:16 AM 
> 	To: Jakarta Commons Developers List 
> 	Cc: 
> 	Subject: Re: cvs commit: jakarta-commons/math/src/test/org/apache/commons/math/linear RealMatrixImplTest.java
> 	
> 	
> 
> 	Mark R. Diggory wrote:
> 	> Hey Phil,
> 	>
> 	> Thanks for working on the RealMatrixImpl, it really gets things rolling.
> 	> I was working on some things offline to support it further. One point of
> 	> concern I have is that I thought we were going to make RealMatrixImpl
> 	> "immutable" and allow the submatrix accessors return implementations
> 	> that reference the internal matrix structure.
> 	
> 	Yes, I was planning to remove the setters next.

Ok

> 	>
> 	> So, currently I would recommend our using an implementation of
> 	> RealMatrix that maintains a reference to the original data[][] array and
> 	> the submatix dimensions it is working within on that matrix. I have been
> 	> working on such an implementation upto this point. Your adding the
> 	> methods to the interface is good and I'll start working on
> 	> implementations that use this strategy.
> 	
> 	What do you mean here? I agree with J that getDataRef should be supported
> 	only in the RealMatrixImpl (where I would leave it in)

Yes, what I've been attempting is to isolate the data[][] store from the 
methods so that a method like getDataRef() can actually return the 
data[][] of the original parent matrix.

Then methods such as add(RealMatrix m) actually use information about 
the "bounds"

> 	public RealMatrix add(RealMatrix m) throws IllegalArgumentException {
>         
> 		int rowCount = this.getRowDimension();
>         int columnCount = this.getColumnDimension();
>         
> 		if (columnCount != m.getColumnDimension() ||
> 				rowCount != m.getRowDimension()) {
>             throw new IllegalArgumentException("matrix dimension mismatch");
>         }
>         
> 		double[][] data = this.getDataRef();
> 		
>         double[][] outData = new double[rowCount][columnCount];
> 
>         for (int row = 0; row < rowCount; row++) {
>             for (int col = 0; col < columnCount; col++) {
>                 outData[row][col] = data[row + ROWMIN][col + COLMIN] + m.getEntry(row,col);
>             }
>         }
>         return new RealMatrixImpl(outData);
> 
>     }

where the implementation maintains what the ROWMIN, ROWMAX, COLMIN, 
COLMAX. and transposes it when something like getEntry(x,y) is called by 
doing something like.

> public double getEntry(int row, int column)
>     	throws MatrixIndexException {
>     	return getDataRef()[row + ROWMIN][column + COLMIN];
>     }


> 	
> 	>
> 	> I also notice in the implementations there a great degree of "copying"
> 	> by using the "getData() method" going on during the processing of
> 	> methods such as add,subtract etc.
> 	>
> 	> getData()
> 	> http://jakarta.apache.org/commons/math/xref/org/apache/commons/math/linear/RealMatrixImpl.html#256
> 	>
> 	getData() is supposed to return a copy of the underlying data.  That is
> 	its contract.

Yes, but it is a copy, not the original, I think we agree that to 
enforce immutability it should remain so.

> 	>
> 	> which calls copyOut(), copying the internal array just to access its
> 	> contents
> 	> http://jakarta.apache.org/commons/math/xref/org/apache/commons/math/linear/RealMatrixImpl.html#821
> 	>
> 	>
> 	> add()
> 	> http://jakarta.apache.org/commons/math/xref/org/apache/commons/math/linear/RealMatrixImpl.html#141
> 	>
> 	Yes, that should be fixed. getDataRef should be used in place of getData
> 	to get the data for the instance.

Yes, but we are restricted to casting to some implementation of 
getDataRef because we do not want it exposed in the Interface so we need 
to make sure the method is available in the implementation. We might do 
this by establishing and internal service interface that all 
Implementations must also meet.

public interface InternalMatrixSupport {

	public double[][] getDataRef();

}

and require all implementations to support it

public class RealMatrixImpl implements RealMatrix, InternalMatrixSupport{

}

> 	>
> 	
> 	> This seems unnecessary, I think using methods to access the array
> 	> contents of the operand matrix would alleviate this unneeded copying.
> 	> For instance:
> 	>
> 	>> for (int row = 0; row < rowCount; row++) {
> 	>>    for (int col = 0; col < columnCount; col++) {
> 	>>       outData[row][col] = data[row][col] + m.getEntry(row,col);
> 	>>    }
> 	>> }
> 	>
> 	That would work in the current impl, actually even better than using
> 	getDataRef.

Yes, we can take this step now prior to release.

> 	>
> 	> The modifications I am working on include these fixes and produce a
> 	> separate abstract class "AbstractRealMatrix" which supports "storage
> 	> independent" versions of these methods. I'm working to use this Abstract
> 	> implementation to form the basis for RealMatrixImpl and any
> 	> "internalized" versions used to support the column, Row and Submatrices.
> 	
> 	Do we really need this?  Do we need it for 1.0?  Please provide more details.

I'd like to see it if I can implement the Abstract version in time. But 
if scheduling doesn't permit, we can move forward without it. We should 
just make sure we at least get the optimizations we discussed for 
RealMatrixImpl in place.

-- 
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org