commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <p...@steitz.com>
Subject Re: [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 23:22:05 GMT
Mark R. Diggory wrote:
> 
> 
> 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.

That will work OK for the row and column accessors and for ranges of 
contiguous cells; but not for the general case currently enabled via the 
sumMatrix API.  These methods are very flexible and allow you to permute 
rows / columns as well as select ranges.  Keeping track of all of that 
would be intractable.  So, if we do go down this path, the "advanced" 
subMatrix methods will still have to make copies.

Assuming we agree on immutablility, the semantics are no different, so I 
would prefer to focus on getting the 1.0 changes complete, including the 
changes to reduce copy operations internal to methods. Remember that all 
the changes already made still have to be ported to the BigMatrix impl. 
Changing and testing all the methods to work with offsets will be time 
consuming and error prone, so I think it is better to hold off on this 
until post 1.0.  IIUC, this would not require any change to the public 
API, so it can be postponed.

Phil


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


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