commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Heuer <>
Subject Re: [math] RealMatrix Immutability
Date Tue, 12 Oct 2004 15:09:04 GMT

On Tue, 12 Oct 2004, 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.
> >
> > 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).

The double[][] constructor for RealMatrixImpl copies the input array, so
if I want to fill a matrix with values, isn't it more efficient and more
straightforward to simply fill the matrix?

RealMatrix rm = new RealMatrixImpl(10000, 10000);
for (int row = 0, rows = rm.getRowDimension(); row < rows; row++)
  for (int col = 0, cols = rm.getColumnDimension(); col < cols; col++)
    rm.setEntry(row, col, someValue);

> >> 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:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message