commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark R. Diggory" <>
Subject Re: Fwd: [math] Contribution to math.linear - CholeskySolver
Date Mon, 24 Nov 2003 19:27:17 GMT

Paul Libbrecht wrote:

> Mark R. Diggory wrote:
>> I suspect this is an area where discussions concerning encapsulation 
>> and exposure of internal datastructures can get heated. Yes, 
>> unnecessary copying should be avoided when performing Matrix operations.
>> Traditionally, we should possibly consider the usage of methods like 
>> Object[] toArray() of the collections API as a model. Does this 
>> publically exposed method always create a copy of the Collections 
>> internal datastructure? Yes, infact it does:
> True for collections.
> But javax.swing.text.GapContent (which is beloved by many) uses Segments 
> which is a simple way to hack into its array, and known to be such).

hmm, I'll take a look at it, I havn't used it before.

> I agree with the point that using this method to perform each 
> computation (i.e. from the same subclass hierarchy) is a bit heavy...


>> But, well documented behaviors should be made because an Object[] simply 
> [...]> I think we should maintain methods that return a copy and methods 
> that
>> return a reference, I would recommend that methods that return a 
>> reference be protected and used internally for processing methods like 
>> RealMatrixImpl.subtract. your correct about the copying, simply 
>> replacing all the getData() methods with getDataRef() methods solves 
>> this however.
>>     public RealMatrix subtract(RealMatrix m) throws 
>> IllegalArgumentException {
>>        ...
>>         *double[][] mData = m.getDataRef();*
>>         for (int row = 0; row < rowCount; row++) {
>>             for (int col = 0; col < columnCount; col++) {
>>                 outData[row][col] = data[row][col] - mData[row][col];
>>             }
>>         }
>>         return new RealMatrixImpl(outData);
>>     }
> But there could be ten thousand time more "interface" based approaches!
> One thing for sure: a RowIterator and a ColumnIterator are needed, 
> returning vectors... inner class implementations of course.
> Substraction, if it is to return a RealMatrixImpl, should then use these 
> instead of accessing the whole array directly!

Hmm, novel, something that would just return public double next()? I 
suppose it could have additional ListIterator functionality, cursoring, etc.

interface VectorIterator {

    public double next();

    public boolean hasNext();

    public double previous();

    public boolean hasPrevious();

    public double current();

    public int cursor();

    public int size();


> And... I wonder wether it wouldn't make sense to provide the difference 
> of two matrices as being a simple object (implementing matrix) but which 
> stores nothing: simply responds the difference of its two terms 
> every-time it's requested for its value.

*static RealMatrix subtract(RealMatrix arg0, RealMatrix arg1)*

RealMatrix a = ...
RealMatrix b = ...
RealMatrix c = RealMatrix.subtract(a, b);


class Subtract implmenets RealMatrix{
    public Subtract(RealMatrix arg0, RealMatrix arg1)*

RealMatrix a = ...
RealMatrix b = ...
RealMatrix c = new Subtract(a, b);


*RealMatrix subtract(RealMatrix arg0)*

RealMatrix a = ...
RealMatrix b = ...
RealMatrix c = a.subtract(b)

seems there'd be many alternatives...

Mark Diggory
Software Developer
Harvard MIT Data Center

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

View raw message