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
-- Mark Diggory Software Developer Harvard MIT Data Center http://www.hmdc.harvard.edu
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
