commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phil Steitz" <>
Subject [math] RealMatrixImpl changes was: RE: cvs commit: jakarta-commons/math/src/test/org/apache/commons/math/linear
Date Mon, 11 Oct 2004 18:14:19 GMT
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.

	-----Original Message----- 
	From: Phil Steitz 
	Sent: Mon 10/11/2004 10:16 AM 
	To: Jakarta Commons Developers List 
	Subject: Re: cvs commit: jakarta-commons/math/src/test/org/apache/commons/math/linear

	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