commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Heuer <heue...@acm.org>
Subject Re: [math] RealMatrix Immutability
Date Tue, 12 Oct 2004 15:14:32 GMT

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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>


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