On Tue, 12 Oct 2004, 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.
This is similar to how colt matrix views (viewRow, viewColumn, viewSelection, etc.) are implemented (disclaimer: I use colt all the time). michael > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
