commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: cvs commit: jakarta-commons/math/src/test/org/apache/commons/math/linear
Date Mon, 11 Oct 2004 17:16:29 GMT
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.
> 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)

> 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()

getData() is supposed to return a copy of the underlying data.  That is 
its contract.
> which calls copyOut(), copying the internal array just to access its 
> contents

> add()

Yes, that should be fixed. getDataRef should be used in place of getData 
to get the data for the instance.

> 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 
> 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.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message