commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark R. Diggory" <>
Subject Re: [math] RealMatrix Immutability wase: Re: [math] cvs commit: jakarta-commons/math/src/test/org/apache/commons/math/linear
Date Tue, 12 Oct 2004 15:03:58 GMT

Phil Steitz wrote:
> Mark R. Diggory wrote:
>> Phil,
>> I think we wanted to maintain the existence of setEntry/getDataRef API 
>> of the RealMatrixImpl without having it in the RealMatrix Interface. 
>> At least until we come up with a strategy for mutability that made 
>> more sense then these methods. This last change removed it from both.
> getDataRef is still there in RealMatrixImpl, though I am starting to 
> think that we can make it protected.  Either the class is immutable or 
> it is not.  We need to decide. All of the use cases that I have can 
> actually be accomplished with the immutable version, using the algebraic 
> operations exposed in the RealMatrix API.  If others have use cases that 
> require mutability, then we can change it back, but I would like to know 
> what they are.

Thats what I'm hoping to hear from Michael, I want to see solid examples 
of the need.

>> Michael,
>> We are attempting to make the Implementation immutable so that methods 
>> calls such as getColumnMatrix(i) and getSubMatrix(xmin,xmax,ymin,ymax) 
>> will be able to return submatrice objects of the existing data without 
>> duplicating/copying the internal datastore to do so, this will provide 
>> efficient means to access the stored values without performing costly 
>> array copies on what may be very large double[][]'s or copying objects 
>> which may not be in an []. So basically, what we are trying to avoid 
>> is that if I do the following
>> Matrix a = ...
>> Matrix b = a.getColumnMatrix(x);
>> that if (a) is mutable, then doing something like a.setEntry(x,y,d) 
>> will also cause (b) to change, something we should try to avoid, we 
>> are trying to work with these more as mathematical objects and not 
>> necessarily as "Collection objects".
> Yes, but the getSubXxx and getCol, getRow currently make copies. 
> Assuming we retain immutability, this makes no functional difference 
> (another argument for making the class immutable).  

Yes, like I said, this a feature I am working on in my checkout. I 
havn't committed it because it is not complete yet.

> Implementation will 
> be very tricky (and likely very inefficient) if we try to support "data 
> sharing" as you describe. It would also make getDataRef impossible to 
> implement.

Not inefficient, a little complex, yes, but not inefficient, the only 
real difference is "where in" the original datastore data structure (in 
this case the data[][]) your are iterating over, the RealMatrix 
representing the Row column or submatrix is simply maintaining extra 
information about the xmn, xmax, ymin, ymax it represents in the 
original data store. It accesses the original data store using the 
getEntry(x,y) . The x and y are transposed to the appropriate location 
int eh datstore using simple arithmetic.

I think were starting get this thing going in the right direction.


Mark Diggory
Software Developer
Harvard MIT Data Center

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

View raw message