commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <p...@steitz.com>
Subject [math] RealMatrix Immutability wase: Re: [math] cvs commit: jakarta-commons/math/src/test/org/apache/commons/math/linear RealMatrixImplTest.java
Date Tue, 12 Oct 2004 11:11:58 GMT
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.
> 
> 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).  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.

> 
> If you require such mutability, could you take a moment and show an 
> example of the usage you require it for?

I thought at first that I would need mutability in my applications, and I 
think that Kim did as well; but I found that my use of it was just because 
I did not have the right boundary between the double[][] stuff that I was 
doing and the algebraic operations (which is what RealMatrix is for).


>> I also wanted to mention that I feel that this interface and its
>> implementation seem too closely intertwined with double arrays, as if
>> clients of the API are going to be moving back and forth between the
>> two data representations regularly.

Well, many clients will in fact be doing that, though hopefully with clean 
boundaries.  Can you suggest alternatives that do not impose too much 
overhead?
>>
>> With the Collections interfaces, if I want a List, I'm going to use
>> one, not go back and forth between Lists and arrays.  Similarly, if I 
>> want
>> to use a RealMatrix, I'd like to use one, not go back and forth 
>> between it
>> and 1D and 2D double arrays.

That's sort of the point of the immutability argument above.  The double[] 
and double[][] valued accessors are for convenience and speed when 
crossing the boundary back into the client application.  Some applications 
will start with arrays, use RealMatrix to perform algebraic operations and 
then use "output" arrays directly.  That is why the accessors are there.

Thanks for the feedback.

Phil



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


Mime
View raw message